CVE-2025-38154

bpf, sockmap: Avoid using sk_socket after free when sending

7.8 HighFix available

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

bpf, sockmap: Avoid using sk_socket after free when sending

The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected.

Race conditions: ''' CPU0 CPU1

backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } '''

Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.

If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync().

In summary, we require synchronization to coordinate the backlog thread and close() thread.

The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''

Attack profile

How easy it is to exploit

Attack vector: Local
Complexity: Low
Privileges needed: Low
User interaction: None

What an attacker can affect

Confidentiality: High
Integrity: High
Availability: High

Exploit likelihood

0.19%Up 0.2 points since Jul 3, 2025

What each source reports

CVE List Score used 7.8

bpf, sockmap: Avoid using sk_socket after free when sending

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

bpf, sockmap: Avoid using sk_socket after free when sending

Race conditions: ''' CPU0 CPU1

backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.

In summary, we require synchronization to coordinate the backlog thread and close() thread.

Record: CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

EUVDEUVD-2025-19790 7.8

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

bpf, sockmap: Avoid using sk_socket after free when sending

Race conditions: ''' CPU0 CPU1

backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.

In summary, we require synchronization to coordinate the backlog thread and close() thread.

Record: EUVD-2025-19790
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

GitHub AdvisoriesGHSA-vvj3-j4jg-68hm 7.8

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Avoid using...

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

bpf, sockmap: Avoid using sk_socket after free when sending

Race conditions: ''' CPU0 CPU1

backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.

In summary, we require synchronization to coordinate the backlog thread and close() thread.

Record: GHSA-vvj3-j4jg-68hm
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness: CWE-416
Updated: 2026-11-02

NVD 7.8

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

bpf, sockmap: Avoid using sk_socket after free when sending

Race conditions: ''' CPU0 CPU1

backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.

In summary, we require synchronization to coordinate the backlog thread and close() thread.

Record: CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Weakness: CWE-416
Updated: 2026-11-02

OSVBELL-CVE-2025-38154 7.8

Record: BELL-CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSV 7.8

bpf, sockmap: Avoid using sk_socket after free when sending

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

bpf, sockmap: Avoid using sk_socket after free when sending

Race conditions: ''' CPU0 CPU1

backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work.

In summary, we require synchronization to coordinate the backlog thread and close() thread.

Record: CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

Show 46 moreShow less

OSVDEBIAN-CVE-2025-38154 7.8

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Avoid using sk_socket after free when sending The sk->sk_socket is not locked or referenced in backlog thread, and during the call to skb_send_sock(), there is a race condition with the release of sk_socket. All types of sockets(tcp/udp/unix/vsock) will be affected. Race conditions: ''' CPU0 CPU1 backlog::skb_send_sock sendmsg_unlocked sock_sendmsg sock_sendmsg_nosec close(fd): ... ops->release() -> sock_map_close() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here ''' The ref of psock become 0 after sock_map_close() executed. ''' void sock_map_close() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sock_map_remove_links(sk, psock) psock = sk_psock_get(sk); if (unlikely(!psock)) goto no_psock; <=== Control jumps here via goto ... cancel_delayed_work_sync(&psock->work); <=== not executed sk_psock_put(sk, psock); ... } ''' Based on the fact that we already wait for the workqueue to finish in sock_map_close() if psock is held, we simply increase the psock reference count to avoid race conditions. With this patch, if the backlog thread is running, sock_map_close() will wait for the backlog thread to complete and cancel all pending work. If no backlog running, any pending work that hasn't started by then will fail when invoked by sk_psock_get(), as the psock reference count have been zeroed, and sk_psock_drop() will cancel all jobs via cancel_delayed_work_sync(). In summary, we require synchronization to coordinate the backlog thread and close() thread. The panic I catched: ''' Workqueue: events sk_psock_backlog RIP: 0010:sock_sendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? die_addr+0x40/0xa0 ? exc_general_protection+0x14c/0x230 ? asm_exc_general_protection+0x26/0x30 ? sock_sendmsg+0x21d/0x440 ? sock_sendmsg+0x3e0/0x440 ? __pfx_sock_sendmsg+0x10/0x10 __skb_send_sock+0x543/0xb70 sk_psock_backlog+0x247/0xb80 ... '''

Record: DEBIAN-CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-2120 8.0

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

gtp: Destroy device along with udp socket's netns dismantle.

gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.

Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]

In this example, gtp0 is created in ns2, and the udp socket is created in ns1.

ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1

Let's link the device to the socket's netns instead.

Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.

[0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)

WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanup_net RIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work…

Record: OESA-2025-2120
CVSS 3.1: 8.0 HighCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-2121 8.0

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

gtp: Destroy device along with udp socket's netns dismantle.

gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.

Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]

In this example, gtp0 is created in ns2, and the udp socket is created in ns1.

ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1

Let's link the device to the socket's netns instead.

Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.

Record: OESA-2025-2121
CVSS 3.1: 8.0 HighCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2025-2122 8.0

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

gtp: Destroy device along with udp socket's netns dismantle.

gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.

Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]

In this example, gtp0 is created in ns2, and the udp socket is created in ns1.

ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1

Let's link the device to the socket's netns instead.

Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.

Record: OESA-2025-2122
CVSS 3.1: 8.0 HighCVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVOESA-2026-1341 7.8

kernel security update

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ( mem hotunplug: fix kfree() of bootmemmemory ), we could get a resource allocated during boot viaalloc_resource(). And it s required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.(CVE-2022-49190)

In the Linux kernel, the following vulnerability has been resolved:drivers: staging: rtl8723bs: Fix deadlock in rtw_surveydone_event_callback()There is a deadlock in rtw_surveydone_event_callback(),which is shown below: (Thread 1) | (Thread 2) | _set_timer()rtw_surveydone_event_callback()| mod_timer() spin_lock_bh() //(1) | (wait a time) ... | rtw_scan_timeout_handler() del_timer_sync() | spin_lock_bh() //(2) (wait timer to stop) | ...We hold pmlmepriv->lock in position (1) of thread 1 and usedel_timer_sync() to wait timer to stop, but timer handleralso need pmlmepriv->lock in position (2) of thread 2.As a result, rtw_surveydone_event_callback() will block forever.This patch extracts del_timer_sync() from the protection ofspin_lock_bh(), which could let timer handler to obtainthe needed lock. What`s more, we change spin_lock_bh() inrtw_scan_timeout_handler() to spin_lock_irq(). Otherwise,spin_lock_bh() will also cause deadlock() in timer handler.(CVE-2022-49309)

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

drm/scheduler: fix fence ref counting

We leaked dependency fences when processes were beeing killed.

Additional to that grab a reference to the last scheduled fence.(CVE-2022-49829)

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

usb: cdns3: fix random warning message when driver load

Warning log: [ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code! [ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20 [ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT) [ 4.163155] Call trace: [ 4.165600] dump_backtrace+0x0/0x1b0 [ 4.169286] show_stack+0x18/0x68 [ 4.172611] dump_stack_lvl+0x68/0x84 [ 4.176286] dump_stack+0x18/0x34 [ 4.179613] kmalloc_fix_flags+0x60/0x88 [ 4.183550] new_slab+0x334/0x370 [ 4.186878] ___slab_alloc.part.108+0x4d4/0x748 [ 4.191419] __slab_alloc.isra.109+0x30/0x78 [ 4.195702] kmem_cache_alloc+0x40c/0x420 [ 4.199725] dma_pool_alloc+0xac/0x1f8 [ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0

pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags) { ... page = kmalloc(sizeof(*page), mem_flags); page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation, &page->dma, mem_flags); ... }

kmalloc was called with mem_flags, which is passed down in cdns3_allocate_trb_pool() and have GFP_DMA32 flags. kmall_fix_flags() report warning.

GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle DMA memory region correctly by pool->dev. GFP_DMA32 can be removed safely.(CVE-2022-50151)

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

of: check previous kernel's ima-kexec-buffer against memory bounds

Presently ima_get_kexec_buffer() doesn't check if the previous kernel's ima-kexec-buffer lies outside the addressable memory range. This can result in a kernel panic if the new kernel is booted with 'mem=X' arg and the ima-kexec-buffer was allocated beyond that range by the previous kernel. The panic is usually of the form below:

$ sudo kexec --initrd initrd vmlinux --append='mem=16G'

<snip> BUG: Unable to handle kernel data access on read at…

Record: OESA-2026-1341
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVRHSA-2026:27731 8.7

Red Hat Security Advisory: kernel security, bug fix, and enhancement update

Record: RHSA-2026:27731
CVSS 3.1: 8.7 HighCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N
Updated: 2026-11-02

OSVRHSA-2026:3520 6.7

Red Hat Security Advisory: kernel security update

Record: RHSA-2026:3520
CVSS 3.1: 6.7 MediumCVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVRHSA-2026:5690 7.5

Red Hat Security Advisory: kernel-rt security update

Record: RHSA-2026:5690
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVRHSA-2026:5813 7.5

Red Hat Security Advisory: kernel security update

Record: RHSA-2026:5813
CVSS 3.1: 7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated: 2026-11-02

OSVRHSA-2026:6310 7.8

Red Hat Security Advisory: kernel security update

Record: RHSA-2026:6310
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVRHSA-2026:7013 7.3

Red Hat Security Advisory: kernel security update

Record: RHSA-2026:7013
CVSS 3.1: 7.3 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
Updated: 2026-11-02

OSVRHSA-2026:7100 7.3

Red Hat Security Advisory: kernel-rt security update

Record: RHSA-2026:7100
CVSS 3.1: 7.3 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H
Updated: 2026-11-02

OSVROOT-OS-DEBIAN-12-CVE-2025-38154 7.8

CVE-2025-38154 in linux - Patched by Root

Root has patched CVE-2025-38154 in the linux package for Root:Debian:12. Multiple fixed versions available.

Record: ROOT-OS-DEBIAN-12-CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVROOT-OS-UBUNTU-2204-CVE-2025-38154 7.8

CVE-2025-38154 in linux - Patched by Root

Root has patched CVE-2025-38154 in the linux package for Root:Ubuntu:22.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2204-CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVROOT-OS-UBUNTU-2404-CVE-2025-38154 7.8

CVE-2025-38154 in linux - Patched by Root

Root has patched CVE-2025-38154 in the linux package for Root:Ubuntu:24.04. Multiple fixed versions available.

Record: ROOT-OS-UBUNTU-2404-CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVUBUNTU-CVE-2025-38154 7.8

Record: UBUNTU-CVE-2025-38154
CVSS 3.1: 7.8 HighCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Updated: 2026-11-02

OSVCLSA-2026-1782155469 No score

kernel: Fix of 143 CVEs

ice: Fix PTP NULL pointer dereference during VSI rebuild {CVE-2026-23210}
tracing: Add recursion protection in kernel stack trace recording {CVE-2026-23138}
mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd() {CVE-2025-38681}
cpuset: fix warning when disabling remote partition {CVE-2025-71142}
virtio: break and reset virtio devices on device_shutdown() {CVE-2025-38064}
netdevsim: fix a race issue related to the operation on bpf_bound_progs list {CVE-2026-23126}
atm: clip: Fix potential null-ptr-deref in to_atmarpd(). {CVE-2025-38460}
idpf: fix error handling in the init_task on load {CVE-2026-23017}
rxrpc: Fix recvmsg() unconditional requeue {CVE-2026-23066}
block: zero non-PI portion of auto integrity buffer {CVE-2026-23007}
can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_mode {CVE-2025-38665}
virtio_net: Fix napi_skb_cache_put warning {CVE-2024-43835}
crypto: af_alg - Disallow concurrent writes in af_alg_sendmsg {CVE-2025-39964}
mptcp: fix race in mptcp_pm_nl_flush_addrs_doit() {CVE-2026-23169}
net: fix segmentation of forwarding fraglist GRO {CVE-2026-23154}
gfs2: Validate i_depth for exhash directories {CVE-2025-38710}
KVM: Don't clobber irqfd routing type when deassigning irqfd {CVE-2026-23198}
ipvlan: Make the addrs_lock be per port {CVE-2026-23103}
xfs: fix freemap adjustments when adding xattrs to leaf blocks {CVE-2026-43158}
can: mcp251xfd: fix infinite loop when xmit fails {CVE-2024-41088}
RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctly {CVE-2025-71096}
RDMA/mlx5: Fix error flow upon firmware failure for RQ destruction {CVE-2025-38161}
scsi: qla2xxx: Validate sp before freeing associated memory {CVE-2025-71236}
net/sched: netem: account for backlog updates from child qdisc {CVE-2024-56770}
drm/i915/gt: fix refcount underflow in intel_engine_park_heartbeat {CVE-2026-31656}
iavf: fix off-by-one issues in iavf_config_rss_reg() {CVE-2025-71087}
net/sched: ets: fix divide by zero in the offload path {CVE-2026-23379}
can: j1939: implement NETDEV_UNREGISTER notification handler {CVE-2025-39925}
ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop() {CVE-2026-31531}
Bluetooth: L2CAP: Fix null-ptr-deref on l2cap_sock_ready_cb {CVE-2026-31510}
ip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv() {CVE-2026-23003}
drm/i915/gt: Check set_default_submission() before deferencing {CVE-2026-31540}
mac802154: check local interfaces before deleting sdata list {CVE-2024-57948}
lib/buildid: use __kernel_read() for sleepable context {CVE-2026-23002}
scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs {CVE-2023-52808}
net: fix memory leak in skb_segment_list for GRO packets {CVE-2026-22979}
irqchip/imx-irqsteer: Handle runtime power management correctly {CVE-2024-42290}
io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop {CVE-2026-23113}
net/sched: ets: Remove drr class from the active list if it changes to strict {CVE-2025-68815}
net: bonding: fix NULL deref in bond_debug_rlb_hash_show {CVE-2026-31546}
ipvs: fix ipv4 null-ptr-deref in route error path {CVE-2025-68813}
openvswitch: fix lockup on tx to unregistering netdev with carrier {CVE-2025-21681}
net: USB: Fix wrong-direction WARNING in plusb.c {CVE-2023-52742}
module: Fix kernel panic when a symbol st_shndx is out of bounds {CVE-2026-31521}
udf: Fix preallocation discarding at indirect extent boundary {CVE-2022-48946}
net/mlx5: qos: Restrict RTNL area to avoid a lock cycle {CVE-2025-39947}
scsi: core: Wake up the error handler when final completions race against each other {CVE-2026-23110}
nbd: don't allow reconnect after disconnect {CVE-2025-21731}
nfsd: check that server is running in unlock_filesystem {CVE-2026-22989}
af_key: validate families in pfkey_send_migrate() {CVE-2026-31515}
netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu() {CVE-2024-36286} -…

Record: CLSA-2026-1782155469
Updated: 2026-11-02

OSVMGASA-2025-0218 No score

Updated kernel-linus packages fix security vulnerabilities

Vanilla upstream kernel version 6.6.101 fixes bugs and vulnerabilities. For information about the vulnerabilities see the links.

Record: MGASA-2025-0218
Updated: 2026-11-02

OSVMGASA-2025-0219 No score

Updated kernel, kmod-virtualbox, kmod-xtables-addons & wireless-regdb packages fix security vulnerabilities

Upstream kernel version 6.6.101 fixes bugs and vulnerabilities. The kmod-virtualbox, kmod-xtables-addons & wireless-regdb packages have been updated to work with this new kernel. For information about the vulnerabilities see the links.

Record: MGASA-2025-0219
Updated: 2026-11-02

OSVopenSUSE-SU-2025:20081-1 No score