Most recent entries from all

bdu:2026-15216

BELL-CVE-2026-80521

Affected: Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

certfr-2026-avi-1253 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Certaines d'entre elles permettent à un…

certfr-2026-avi-1253

fkie_cve-2026-80521

In the Linux kernel, the following vulnerability has been resolved:

af_unix: Unlink scc_entry in unix_del_edge().

Kyle Zeng reported that GC could free a dead SCC partially.

The scenario is as follows:

1) Create two SCCs:

X -. A <-> B ^--'

2) Run the following concurrently:

2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B

At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail().

If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge.

X -. A <-> B -. This edge is visible ^--' ^..' but skb is not

This itself is not a problem since the next GC run will judge B as dead as well and free it finally.

X -. A <.> B -. ^--' ^--'

However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry.

Let's unlink scc_entry before freeing the vertex in unix_del_edge().

GHSA-g8mr-r59r-2xmq

In the Linux kernel, the following vulnerability has been resolved:

af_unix: Unlink scc_entry in unix_del_edge().

Kyle Zeng reported that GC could free a dead SCC partially.

The scenario is as follows:

1) Create two SCCs:

X -. A <-> B ^--'

2) Run the following concurrently:

2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B

At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail().

If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge.

X -. A <-> B -. This edge is visible ^--' ^..' but skb is not

This itself is not a problem since the next GC run will judge B as dead as well and free it finally.

X -. A <.> B -. ^--' ^--'

However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry.

Let's unlink scc_entry before freeing the vertex in unix_del_edge().

msrc_CVE-2026-80521 — af_unix: Unlink scc_entry in unix_del_edge().

msrc_CVE-2026-80521

RHSA-2026:77634 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update

kernel: fs/notify: call exportfs_encode_fid with s_umount kernel: ipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data() kernel: udf: fix partition descriptor append bookkeeping kernel: sctp: purge outqueue on stale COOKIE-ECHO handling kernel: netfilter: synproxy: refresh tcphdr after skb_ensure_writable kernel: smb: client: fix double-free in SMB2_flush() replay kernel: Kernel SMB client: Double-free vulnerability allows remote denial of service or privilege escalation kernel: smb: client: fix query_info() replay double-free kernel: udp: fix potential use-after-free in tunnel segmentation kernel: af_unix: Unlink scc_entry in unix_del_edge()

UBUNTU-CVE-2026-80521

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 154 more

In the Linux kernel, the following vulnerability has been resolved: af_unix: Unlink scc_entry in unix_del_edge(). Kyle Zeng reported that GC could free a dead SCC partially. The scenario is as follows: 1) Create two SCCs: X -. A <-> B ^--' 2) Run the following concurrently: 2-1) send() sk-B to sk-B from sk-X 2-2) close() both A and B At 2-1), there is a small window where unix_add_edges() publishes a new edge (B <-> B) to GC but its skb is not queued by skb_queue_tail(). If 2-2) completes before skb_queue_tail() and GC is triggered, it judges A <-> B as dead, but B is not freed because GC cannot collect the not-yet-queued skb holding the B <-> B edge. X -. A <-> B -. This edge is visible ^--' ^..' but skb is not This itself is not a problem since the next GC run will judge B as dead as well and free it finally. X -. A <.> B -. ^--' ^--' However, X's SCC forces the next GC to call unix_walk_scc_fast(), and it iterates over A through B's scc_entry. Let's unlink scc_entry before freeing the vertex in unix_del_edge().