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

EUVD-2026-372818

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

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().

WID-SEC-W-2026-3042 — Linux Kernel: Mehrere Schwachstellen

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, darunter möglicherweise die Ausführung von beliebigem Code, die Ausweitung von Berechtigungen, die Offenlegung von Informationen, die Manipulation von Daten oder Denial-of-Service-Zustände.