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 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb

In the Linux kernel, the following vulnerability has been resolved: bpf: reject short IPv4/IPv6 inputs in bpf_prog_test_run_skb bpf_prog_test_run_skb() calls eth_type_trans() first and then uses skb->protocol to initialize sk family and address fields for the test run. For IPv4 and IPv6 packets, it may access ip_hdr(skb) or ipv6_hdr(skb) even when the provided test input only contains an Ethernet header. Reject the input earlier if the Ethernet frame carries IPv4/IPv6 EtherType but the L3 header is too short. Fold the IPv4/IPv6 header length checks into the existing protocol switch and return -EINVAL before accessing the network headers.

Affected products

Linux
  • ==5.9
  • =<5.15.*
  • =<6.18.*
  • <12bec2bd4b76d81c5d3996bd14ec1b7f4d983747
  • =<6.12.*
  • <e6aa481f21fc7a41ed344767ea25aae9d03fae71
  • =<7.0.*
  • <0a04db240effd85773f66244645a28cedddb72d2
  • <6a9f38d5ff11e00bc54baab752642978805e81eb
  • <6def5fe753cbe5b279ee5fd10327b2611cbddaca
  • <5.9
  • =<*
  • <1f882c492d46f90bdb36f4936876c88c28dab21c
  • <7254267799d083280c0e53effc101a33add95f7b
  • <8042240412de3222d27b31e89d29336961cad9e4
  • =<6.1.*
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers

In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: propagate nvmet_tcp_build_pdu_iovec() errors to its callers Currently, when nvmet_tcp_build_pdu_iovec() detects an out-of-bounds PDU length or offset, it triggers nvmet_tcp_fatal_error(cmd->queue) and returns early. However, because the function returns void, the callers are entirely unaware that a fatal error has occurred and that the cmd->recv_msg.msg_iter was left uninitialized. Callers such as nvmet_tcp_handle_h2c_data_pdu() proceed to blindly overwrite the queue state with queue->rcv_state = NVMET_TCP_RECV_DATA Consequently, the socket receiving loop may attempt to read incoming network data into the uninitialized iterator. Fix this by shifting the error handling responsibility to the callers.

Affected products

Linux
  • <046fa5c72d15cd8e2d592e275697ea399d8f76b0
  • =<6.18.*
  • <5.11
  • =<7.0.*
  • <3df42a854686fa06484e37ac1a3931c8e3e3453c
  • ==42afe8ed8ad2de9c19457156244ef3e1eca94b5d
  • ==043b4307a99f902697349128fde93b2ddde4686c
  • ==6.19
  • =<6.1.*
  • <6.18.33
  • <d7c8f95f599b3b38a717d2e771c3f8c174f657c3
  • <6.19
  • <c2a11441538bdbbc5aa003f190995eba93a89b88
  • <6.1.175
  • <ea8e356acb165cb1fd75537a52e1f66e5e76c538
  • <6.6.141
  • <f9204a2b78dd18374d3bcf9bf93d9021ce22de1b
  • =<*
  • <6.12.91
  • <5.16
  • =<6.12.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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
  • =<5.15.*
  • =<6.18.*
  • =<6.12.*
  • <1921f91298d1388a0bb9db8f83800c998b649cb3
  • =<7.0.*
  • <5.15
  • <183128da0406b1c10e6f60b7b9fe70788b9c8c1d
  • <acbf45bd584d924b320bee2a7fe2a26f64904d95
  • =<*
  • <ea690b3b6e58ae00979af8195b4cc24df466b65e
  • <3128b294b426533c8d9162187446d93a8a160359
  • =<6.1.*
  • ==5.15
  • <866d3d9b87751b1944168fd82615505e0c0fd6cf
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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
  • <1d59f36e95f7f7134db0e313c9d787cb0adb2153
  • <6.15
  • =<7.0.*
  • <9402ad98a047dd9894ec868a7df5ad9bd03327d3
  • ==6.15
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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.13
  • =<6.18.*
  • <5.11
  • =<7.0.*
  • ==5bfb25495e391a1be0db94b15715174fa06b93a1
  • ==2902a9b4415a6bafc9b1e5dd360f065d757a0bb7
  • ==fc188b44547dea4e7350833171982a6312befde9
  • ==7.0
  • <00c0317cebf44151df18fb647781f315268cdd98
  • <6.18.33
  • <6.20
  • ==b82073564373e68c6ae3a96039fae14cd002a496
  • <6.2
  • <7c5c2b661bdb78c1472b8833265c9ed1ee880039
  • ==498525d8358d6d20918787e59736d5b6a021e9fd
  • <7.0
  • ==948a39c95d0f8d73722910f8cdb7b6e3e9206232
  • <4f273d3f98ebc60c30bbfb3ed4a7f0477d3eaed2
  • =<*
  • <6.7
  • <5.16
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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
  • =<7.0.*
  • <965dc93481d1b80d341bdd16c27b16fe197175ee
  • <b34a1d83c74a124c968b5adb25c809db3e2eb86a
  • <5.15
  • =<*
  • ==5.15
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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
  • <585cb85e9a29185be05f326369573c2663cf4380
  • <6.17
  • <7f2fcff15e99bb852f6967396ed12b38376e2c8d
  • =<6.18.*
  • =<7.0.*
  • <5fd1fa5a4254bfdd70571c77f5e3bcb4e43738d5
  • =<*
  • ==6.17
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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
  • <9b0cf064ea0a6bac5e1a5fb43b004fd52fbe2b3b
  • =<7.0.*
  • <f74fce43dbc059e059b5346a670f697c0e97b1d0
  • =<*
  • ==7.0
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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
  • <ac4d8bb6e2e13e8684a76ea48d13ebaaaf5c24c4
  • <c4295487124f461405e1ef64dfa8c4ab0cb7ebcf
  • =<6.18.*
  • =<6.12.*
  • <106d594711e97762788046c5bbb94f580abc4bf4
  • =<7.0.*
  • <5.3
  • <2081957d8c323ffb58a10bc64837717ac5a042a1
  • =<*
  • <b660ba045b2b22cf3b4be72773de00cb48f47be5
  • ==5.3
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days 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
  • =<7.0.*
  • =<*
  • <ef2d97c15b19b3489de01695bce478601e236c3e
  • <4.9