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 ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tipc: fix double-free in tipc_buf_append()

In the Linux kernel, the following vulnerability has been resolved: tipc: fix double-free in tipc_buf_append() tipc_msg_validate() can potentially reallocate the skb it is validating, freeing the old one. In tipc_buf_append(), it was being called with a pointer to a local variable which was a copy of the caller's skb pointer. If the skb was reallocated and validation subsequently failed, the error handling path would free the original skb pointer, which had already been freed, leading to double-free. Fix this by checking if head now points to a newly allocated reassembled skb. If it does, reassign *headbuf for later freeing operations.

Affected products

Linux
  • <0274f24485fc38032d4093e463dc3ff5c7a667c9
  • =<5.15.*
  • =<6.18.*
  • <4d104882bc815d4ec666ace9155f5f52715879a6
  • <29940fff14110ca48c5ccc168d121665b51bb778
  • =<6.12.*
  • =<7.0.*
  • <4ee4deadaae7cb2e3d53af0fc889cf92a73413c0
  • <4.15
  • <d3556656c6daebf8def751c7e71d11dd0a180d24
  • =<*
  • <a438975a6dcdbd70865978c021650d1485586f0b
  • <1d5e589055880fae229e229e1929e087dbe08cf3
  • <d293ca716e7d5dffdaecaf6b9b2f857a33dc3d3a
  • =<6.1.*
  • =<5.10.*
  • ==4.15
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg

In the Linux kernel, the following vulnerability has been resolved: NFSD: fix nfs4_file access extra count in nfsd4_add_rdaccess_to_wrdeleg In nfsd4_add_rdaccess_to_wrdeleg, if fp->fi_fds[O_RDONLY] is already set by another thread, __nfs4_file_get_access should not be called to increment the nfs4_file access count since that was already done by the thread that added READ access to the file. The extra fi_access count in nfs4_file can prevent the corresponding nfsd_file from being freed. When stopping nfs-server service, these extra access counts trigger a BUG in kmem_cache_destroy() that shows nfsd_file object remaining on __kmem_cache_shutdown. This problem can be reproduced by running the Git project's test suite over NFS.

Affected products

Linux
  • =<6.18.*
  • <6.19
  • =<7.0.*
  • =<*
  • <b81572b073441dfd32213e41857676d0dbff4665
  • <4584229395d0d65bd517780afe97ffea07cb2c3d
  • <b48f44f36e6607b2f818560f19deb86b4a9c717b
  • ==6.19
  • <6.18.33
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nexthop: fix IPv6 route referencing IPv4 nexthop

In the Linux kernel, the following vulnerability has been resolved: nexthop: fix IPv6 route referencing IPv4 nexthop syzbot reported a panic [1] [2]. When an IPv6 nexthop is replaced with an IPv4 nexthop, the has_v4 flag of all groups containing this nexthop is not updated. This is because nh_group_v4_update is only called when replacing AF_INET to AF_INET6, but the reverse direction (AF_INET6 to AF_INET) is missed. This allows a stale has_v4=false to bypass fib6_check_nexthop, causing IPv6 routes to be attached to groups that effectively contain only AF_INET members. Subsequent route lookups then call nexthop_fib6_nh() which returns NULL for the AF_INET member, leading to a NULL pointer dereference. Fix by calling nh_group_v4_update whenever the family changes, not just AF_INET to AF_INET6. Reproducer: # AF_INET6 blackhole ip -6 nexthop add id 1 blackhole # group with has_v4=false ip nexthop add id 100 group 1 # replace with AF_INET (no -6), has_v4 stays false ip nexthop replace id 1 blackhole # pass stale has_v4 check ip -6 route add 2001:db8::/64 nhid 100 # panic ping -6 2001:db8::1 [1] https://syzkaller.appspot.com/bug?id=e17283eb2f8dcf3dd9b47fe6f67a95f71faadad0 [2] https://syzkaller.appspot.com/bug?id=8699b6ae54c9f35837d925686208402949e12ef3

Affected products

Linux
  • <9c2d6770a5f4545a307eb66979bef7656a34d621
  • =<6.1.*
  • =<5.15.*
  • =<6.18.*
  • <aaac3bed034239e1d75732211d9b05f30b0b4f35
  • <b3b7e850e1541f0520c4a12ec884255c30427ff6
  • <613c8f4a501421dd258b07ea614205d4e16ec845
  • =<6.12.*
  • <ceffe81a0be92afc0cd1340bc8ca46559cce9bb4
  • <29c95185ba32b621fbc3800fb86e7dc3edf5c2be
  • =<7.0.*
  • <5.3
  • <6275796f22bb382f3e9aa58ed0b4ef7bdad78cb8
  • <ad85961004fd4bd2f31209ac4b07612c6cefb9e7
  • =<*
  • ==5.3
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
xfrm: ipcomp: Free destination pages on acomp errors

In the Linux kernel, the following vulnerability has been resolved: xfrm: ipcomp: Free destination pages on acomp errors Move the out_free_req label up by a couple of lines so that the allocated dst SG list gets freed on error as well as success.

Affected products

Linux
  • <6.15
  • =<6.18.*
  • <dc6dcba80d72a27ab61831ad3d253316e0c9b9d5
  • =<7.0.*
  • <b30aa173c3809f6af4c83a86099be1be19aa48eb
  • ==6.15
  • =<*
  • <7dbac7680eb629b3b4dc7e98c34f943b8814c0c8
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Fix use-after-free in offloaded map/prog info fill

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in offloaded map/prog info fill When querying info for an offloaded BPF map or program, bpf_map_offload_info_fill_ns() and bpf_prog_offload_info_fill_ns() obtain the network namespace with get_net(dev_net(offmap->netdev)). However, the associated netdev's netns may be racing with teardown during netns destruction. If the netns refcount has already reached 0, get_net() performs a refcount_t increment on 0, triggering: refcount_t: addition on 0; use-after-free. Although rtnl_lock and bpf_devs_lock ensure the netdev pointer remains valid, they cannot prevent the netns refcount from reaching zero. Fix this by using maybe_get_net() instead of get_net(). maybe_get_net() uses refcount_inc_not_zero() and returns NULL if the refcount is already zero, which causes ns_get_path_cb() to fail and the caller to return -ENOENT -- the correct behavior when the netns is being destroyed.

Affected products

Linux
  • <a0c584fc18056709c8e047a82a6045d6c209f4ce
  • ==4.16
  • <4.16
  • =<7.0.*
  • =<*
  • <a51e7fbe94a87e236631a83973d4f558310b2cd2
Dismissed
(max. allowed matches exceeded)
created 3 weeks 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 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 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 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 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