Nixpkgs security tracker

Login with GitHub
⚠️ You are using a production deployment that is still only suitable for demo purposes. Any work done in this might be wiped later without notice.

Dismissed suggestions

These automatic suggestions were dismissed after initial triaging.

to select a suggestion for revision.

View:
Compact
Detailed
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master

In the Linux kernel, the following vulnerability has been resolved: net, bpf: fix null-ptr-deref in xdp_master_redirect() for down master syzkaller reported a kernel panic in bond_rr_gen_slave_id() reached via xdp_master_redirect(). Full decoded trace: https://syzkaller.appspot.com/bug?extid=80e046b8da2820b6ba73 bond_rr_gen_slave_id() dereferences bond->rr_tx_counter, a per-CPU counter that bonding only allocates in bond_open() when the mode is round-robin. If the bond device was never brought up, rr_tx_counter stays NULL. The XDP redirect path can still reach that code on a bond that was never opened: bpf_master_redirect_enabled_key is a global static key, so as soon as any bond device has native XDP attached, the XDP_TX -> xdp_master_redirect() interception is enabled for every slave system-wide. The path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() then runs against a bond that has no rr_tx_counter and crashes. Fix this in the generic xdp_master_redirect() by refusing to call into the master's ->ndo_xdp_get_xmit_slave() when the master device is not up. IFF_UP is only set after ->ndo_open() has successfully returned, so this reliably excludes masters whose XDP state has not been fully initialized. Drop the frame with XDP_ABORTED so the exception is visible via trace_xdp_exception() rather than silently falling through. This is not specific to bonding: any current or future master that defers XDP state allocation to ->ndo_open() is protected.

Affected products

Linux
  • <7bad93e99737e4a5c0c14ac50c05152cf4e28022
  • =<6.12.*
  • <acbf45bd584d924b320bee2a7fe2a26f64904d95
  • =<6.18.*
  • =<*
  • <1921f91298d1388a0bb9db8f83800c998b649cb3
  • <5.15
  • <183128da0406b1c10e6f60b7b9fe70788b9c8c1d
  • =<6.1.*
  • <866d3d9b87751b1944168fd82615505e0c0fd6cf
  • =<6.6.*
  • =<7.0.*
  • ==5.15
  • <ea690b3b6e58ae00979af8195b4cc24df466b65e
  • <3128b294b426533c8d9162187446d93a8a160359
  • =<5.15.*
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure

In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix ttm_bo_shrink() infinite LRU walk on backup failure Apply the same fix as b2ed01e7ad ("drm/ttm: Fix ttm_bo_swapout() infinite LRU walk on swapout failure") to the ttm_bo_shrink() path. Move del_bulk_move from before the backup to after success only, using ttm_resource_del_bulk_move_unevictable() since the resource is now unevictable once fully backed up.

Affected products

Linux
  • ==6.15
  • =<*
  • <6.15
  • =<7.0.*
  • <9402ad98a047dd9894ec868a7df5ad9bd03327d3
  • <1d59f36e95f7f7134db0e313c9d787cb0adb2153
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: libertas: don't kill URBs in interrupt context

In the Linux kernel, the following vulnerability has been resolved: wifi: libertas: don't kill URBs in interrupt context Serialization for the TX path was enforced by calling usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before a previous URB was completed. usb_tx_block() can be called from interrupt context (e.g. in the HCD giveback path), so we can't always use it to kill in-flight URBs. Prevent sleeping during interrupt context by checking the tx_submitted anchor for existing URBs. We now return -EBUSY, to indicate there's a pending request.

Affected products

Linux
  • <6.20
  • <7c5c2b661bdb78c1472b8833265c9ed1ee880039
  • ==2902a9b4415a6bafc9b1e5dd360f065d757a0bb7
  • ==7.0
  • ==948a39c95d0f8d73722910f8cdb7b6e3e9206232
  • <6.2
  • ==fc188b44547dea4e7350833171982a6312befde9
  • <5.11
  • <6.7
  • ==498525d8358d6d20918787e59736d5b6a021e9fd
  • =<7.0.*
  • <00c0317cebf44151df18fb647781f315268cdd98
  • <6.18.33
  • <5.16
  • ==b82073564373e68c6ae3a96039fae14cd002a496
  • ==5bfb25495e391a1be0db94b15715174fa06b93a1
  • <6.13
  • =<*
  • =<6.18.*
  • <7.0
  • <4f273d3f98ebc60c30bbfb3ed4a7f0477d3eaed2
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
af_unix: Drop all SCM attributes for SOCKMAP.

In the Linux kernel, the following vulnerability has been resolved: af_unix: Drop all SCM attributes for SOCKMAP. SOCKMAP can hide inflight fd from AF_UNIX GC. When a socket in SOCKMAP receives skb with inflight fd, sk_psock_verdict_data_ready() looks up the mapped socket and enqueue skb to its psock->ingress_skb. Since neither the old nor the new GC can inspect the psock queue, the hidden skb leaks the inflight sockets. Note that this cannot be detected via kmemleak because inflight sockets are linked to a global list. In addition, SOCKMAP redirect breaks the Tarjan-based GC's assumption that unix_edge.successor is always alive, which is no longer true once skb is redirected, resulting in use-after-free below. [0] Moreover, SOCKMAP does not call scm_stat_del() properly, so unix_show_fdinfo() could report an incorrect fd count. sk_msg_recvmsg() does not support any SCM attributes in the first place. Let's drop all SCM attributes before passing skb to the SOCKMAP layer. [0]: BUG: KASAN: slab-use-after-free in unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) Read of size 8 at addr ffff888125362670 by task kworker/56:1/496 CPU: 56 UID: 0 PID: 496 Comm: kworker/56:1 Not tainted 7.0.0-rc7-00263-gb9d8b856689d #3 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 Workqueue: events sk_psock_backlog Call Trace: <TASK> dump_stack_lvl (lib/dump_stack.c:122) print_report (mm/kasan/report.c:379) kasan_report (mm/kasan/report.c:597) unix_del_edges (net/unix/garbage.c:118 net/unix/garbage.c:181 net/unix/garbage.c:251) unix_destroy_fpl (net/unix/garbage.c:317) unix_destruct_scm (./include/net/scm.h:80 ./include/net/scm.h:86 net/unix/af_unix.c:1976) sk_psock_backlog (./include/linux/skbuff.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258) </TASK> Allocated by task 955: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) __kasan_slab_alloc (mm/kasan/common.c:369) kmem_cache_alloc_noprof (mm/slub.c:4539) sk_prot_alloc (net/core/sock.c:2240) sk_alloc (net/core/sock.c:2301) unix_create1 (net/unix/af_unix.c:1099) unix_create (net/unix/af_unix.c:1169) __sock_create (net/socket.c:1606) __sys_socketpair (net/socket.c:1811) __x64_sys_socketpair (net/socket.c:1863 net/socket.c:1860 net/socket.c:1860) do_syscall_64 (arch/x86/entry/syscall_64.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) Freed by task 496: kasan_save_track (mm/kasan/common.c:58 mm/kasan/common.c:78) kasan_save_free_info (mm/kasan/generic.c:587) __kasan_slab_free (mm/kasan/common.c:287) kmem_cache_free (mm/slub.c:6165) __sk_destruct (net/core/sock.c:2282 net/core/sock.c:2384) sk_psock_destroy (./include/net/sock.h:?) process_scheduled_works (kernel/workqueue.c:?) worker_thread (kernel/workqueue.c:?) kthread (kernel/kthread.c:438) ret_from_fork (arch/x86/kernel/process.c:164) ret_from_fork_asm (arch/x86/entry/entry_64.S:258)

Affected products

Linux
  • <5.15
  • <965dc93481d1b80d341bdd16c27b16fe197175ee
  • ==5.15
  • =<*
  • =<7.0.*
  • <b34a1d83c74a124c968b5adb25c809db3e2eb86a
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tun: zero the whole vnet header in tun_put_user()

In the Linux kernel, the following vulnerability has been resolved: tun: zero the whole vnet header in tun_put_user() tun_put_user() declares an on-stack struct virtio_net_hdr_v1_hash_tunnel without zeroing it. For a non-tunnel skb, virtio_net_hdr_tnl_from_skb() only initializes the first 10 bytes (sizeof(struct virtio_net_hdr)), leaving bytes 10..23 (num_buffers and the hash/tunnel fields) as stack garbage. An unprivileged user can set the vnet header size to 24 with TUNSETVNETHDRSZ, so __tun_vnet_hdr_put() copies all 24 bytes of the partially-initialized struct to userspace, leaking 14 bytes of kernel stack on every read of a non-tunnel packet. Fix it the same way tun_get_user() already does by zeroing the whole header right after declaration.

Affected products

Linux
  • <7f2fcff15e99bb852f6967396ed12b38376e2c8d
  • ==6.17
  • <585cb85e9a29185be05f326369573c2663cf4380
  • =<7.0.*
  • =<*
  • =<6.18.*
  • <5fd1fa5a4254bfdd70571c77f5e3bcb4e43738d5
  • <6.17
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Switch CONFIG_CFI_CLANG to CONFIG_CFI

In the Linux kernel, the following vulnerability has been resolved: bpf: Switch CONFIG_CFI_CLANG to CONFIG_CFI This was renamed in commit 23ef9d439769 ("kcfi: Rename CONFIG_CFI_CLANG to CONFIG_CFI") as it is now a compiler-agnostic option. Using the wrong name results in the code getting compiled out. Meaning the CFI failures for btf_dtor_kfunc_t would still trigger.

Affected products

Linux
  • ==7.0
  • <f74fce43dbc059e059b5346a670f697c0e97b1d0
  • <9b0cf064ea0a6bac5e1a5fb43b004fd52fbe2b3b
  • =<*
  • =<7.0.*
  • <7.0
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
s390/cio: use generic driver_override infrastructure

In the Linux kernel, the following vulnerability has been resolved: s390/cio: use generic driver_override infrastructure When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF. Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally. Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

Affected products

Linux
  • <5.3
  • <106d594711e97762788046c5bbb94f580abc4bf4
  • <ac4d8bb6e2e13e8684a76ea48d13ebaaaf5c24c4
  • <2081957d8c323ffb58a10bc64837717ac5a042a1
  • <c4295487124f461405e1ef64dfa8c4ab0cb7ebcf
  • =<7.0.*
  • =<6.18.*
  • =<*
  • <b660ba045b2b22cf3b4be72773de00cb48f47be5
  • =<6.12.*
  • ==5.3
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
greybus: raw: fix use-after-free on cdev close

In the Linux kernel, the following vulnerability has been resolved: greybus: raw: fix use-after-free on cdev close This addresses a use-after-free bug when a raw bundle is disconnected but its chardev is still opened by an application. When the application releases the cdev, it causes the following panic when init on free is enabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y): refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130 ... Call Trace: <TASK> cdev_put+0x18/0x30 __fput+0x255/0x2a0 __x64_sys_close+0x3d/0x80 do_syscall_64+0xa4/0x290 entry_SYSCALL_64_after_hwframe+0x77/0x7f The cdev is contained in the "gb_raw" structure, which is freed in the disconnect operation. When the cdev is released at a later time, cdev_put gets an address that points to freed memory. To fix this use-after-free, convert the struct device from a pointer to being embedded, that makes the lifetime of the cdev and of this device the same. Then, use cdev_device_add, which guarantees that the device won't be released until all references to the cdev have been released. Finally, delegate the freeing of the structure to the device release function, instead of freeing immediately in the disconnect callback.

Affected products

Linux
  • <983cc2c7efbce04ecbf6328448d895044dd6ab31
  • <4.9
  • <ef2d97c15b19b3489de01695bce478601e236c3e
  • ==4.9
  • =<7.0.*
  • =<*
Dismissed
(max. allowed matches exceeded)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: ebtables: fix OOB read in compat_mtw_from_user

In the Linux kernel, the following vulnerability has been resolved: netfilter: ebtables: fix OOB read in compat_mtw_from_user Luxiao Xu says: The function compat_mtw_from_user() converts ebtables extensions from 32-bit user structures to kernel native structures. However, it lacks proper validation of the user-supplied match_size/target_size. When certain extensions are processed, the kernel-side translation logic may perform memory accesses based on the extension's expected size. If the user provides a size smaller than what the extension requires, it results in an out-of-bounds read as reported by KASAN. This fix introduces a check to ensure match_size is at least as large as the extension's required compatsize. This covers matches, watchers, and targets, while maintaining compatibility with standard targets. AFAIU this is relevant for matches that need to go though match->compat_from_user() call. Those that use plain memcpy with the user-provided size are ok because the caller checks that size vs the start of the next rule entry offset (which itself is checked vs. total size copied from userspace). The ->compat_from_user() callbacks assume they can read compatsize bytes, so they need this extra check. Based on an earlier patch from Luxiao Xu.

Affected products

Linux
  • <7ad0e463fc7eafae2141cc38054264636f8b3e94
  • <d7a8fb6f10d55a1c37b0bf8c20cca24dffd76e00
  • <21af4c030567d2e6c89bb927bc18b51fba52a400
  • <2.6.34
  • =<6.18.*
  • <dad9ebf8107955bb54bd3f9cf22591b6ff37bac1
  • <a27cb7325a6c69970041c7f8541fafed5a1ea3ec
  • <bf8e8eac7ede51dc318e06acef5a896dcbba7595
  • =<5.15.*
  • =<6.1.*
  • <fcc4c043d137e7f1de4673dba1f3116e45377c67
  • =<7.0.*
  • =<*
  • <f438d1786d657d57790c5d138d6db3fc9fdac392
  • ==2.6.34
  • =<6.12.*
  • =<6.6.*
  • =<5.10.*
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-13031
8.8 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): High (H)
  • Integrity (I): High (H)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): High (H)
  • Modified Availability (MA): High (H)
created 2 months, 1 week ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Use after free in Blink in Google Chrome prior to …

Use after free in Blink in Google Chrome prior to 149.0.7827.197 allowed a remote attacker to execute arbitrary code inside a sandbox via a crafted HTML page. (Chromium security severity: High)

Affected products

Chrome
  • <149.0.7827.197