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, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: xt_cluster: reject template conntracks in hash match

In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_cluster: reject template conntracks in hash match xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully initialized conntrack and passes it to xt_cluster_hash(). This causes a state confusion bug when the raw table CT target attaches a template conntrack to skb->_nfct before normal conntrack processing. Templates carry IPS_TEMPLATE status but do not have a valid tuple for hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the zeroed l3num field. Reject template conntracks before hashing them. This matches existing netfilter handling for template objects and avoids hashing incomplete conntrack state.

Affected products

Linux
  • <d5f9d050b0b267227c1f02f11021872c7768a9cc
  • =<5.10.*
  • <07f9ddbf5e799c24a3a52ec9bd7b729a6f6d69d5
  • ==2.6.30
  • <4cb8b5f586e41c187942291cc0938006077fa79e
  • <5feba91006ec92da57acc1cc2e34df623b98541e
  • <fac2fdac3baad9ffd12b3b0bba4374d4b3585d54
  • =<*
  • =<6.6.*
  • <5b2d4f0010018a7aa3495aa1dbf1b7a34011e7aa
  • <13ea4f86cf738c74be2146886ac261988a631e62
  • <2.6.30
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • =<5.15.*
  • <4558bd7b47c7be82dffd837f27be8ea3ecee557d
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/nldev: Fix locking when accessing mr->pd

In the Linux kernel, the following vulnerability has been resolved: RDMA/nldev: Fix locking when accessing mr->pd Sashiko points out that, due to rereg_mr, the PD is actually variable and all the touches in nldev are racy. Use mr->device instead of mr->pd->device. Getting the PD restrack ID is more tricky. To avoid disturbing all the happy paths, add an rdma_restrack_sync() operation which is sort of like flush_workqueue() or synchronize_irq(): after it returns, all the old nldev touches to the mr are gone and everything sees the new PD. This makes it safe to reach into the PD pointer.

Affected products

Linux
  • <4.18
  • <50d5c02ab8e62325548bd3a6e6b758a9dcd6e7c3
  • =<*
  • =<7.1.*
  • ==4.18
  • <1a132ee4e655288d9a0937ea5109a0d038431ae9
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
rxrpc: Fix UAF in rxgk_issue_challenge()

In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix UAF in rxgk_issue_challenge() Fix rxgk_issue_challenge() to free the page containing the challenge content after invoking the tracepoint as the whdr passed to the tracepoint points into the page just freed.

Affected products

Linux
  • ==6.16
  • <6.16
  • <83bb0ed050e2ad9453d8ef50e4d6e624eac6eed8
  • =<*
  • <844b8525ce503405c462ad67f750bec648720397
  • =<6.18.*
  • =<7.1.*
  • <107a4cb0d47e735830f852d83970d5c81f8e1e08
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat()

In the Linux kernel, the following vulnerability has been resolved: tpm: tpm_tis_spi: Use wait_woken() in wait_for_tmp_stat() wait_event_interruptible_timeout() evaluates its condition after setting the current task state to TASK_INTERRUPTIBLE. With CONFIG_DEBUG_ATOMIC_SLEEP this triggers a warning when the IRQ wait path is used: tpm_tis_status() tpm_tis_spi_read_bytes() tpm_tis_spi_transfer_full() spi_bus_lock() mutex_lock() Address this with the following measures: 1. Call wait_tpm_stat_cond() only while tasking is running. 2. Use wait_woken() to wait for changes.

Affected products

Linux
  • ==d229e7ecc0cb29996688f0fa98c5eb6128b81e3a
  • =<*
  • <4.15
  • =<6.6.*
  • <4bb3e1bc142dc9c3240ceed1b3ab031aa9cb1723
  • =<7.1.*
  • ==4.19
  • <ba33b4f9d3423accd2c91a0b0b0680cd589922f2
  • <4.19
  • =<6.18.*
  • <bb63a0530e8e6de3aaf29cd5ba487db2490128ef
  • =<6.1.*
  • <c0c9cfb3b75def8bf200a2d4db09015806acfeaf
  • <c9acbe38797bc1aa3c22a1ab72452e210af6e0ff
  • =<6.12.*
  • ==cd4ae0b05126cc9461a2e50ccb745e5583cc91e2
  • <4.19
  • <4.10
  • ==cf503dbe5c22c6ab9797e1cf864a11597d711c3a
  • <6b068a97958aa00a901a9b5083d74114b21f7b66
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: wcn36xx: fix heap overflow from oversized firmware HAL response

In the Linux kernel, the following vulnerability has been resolved: wifi: wcn36xx: fix heap overflow from oversized firmware HAL response The firmware response dispatcher copies all synchronous HAL responses into the 4096-byte hal_buf without validating the response length. A response exceeding WCN36XX_HAL_BUF_SIZE causes a heap buffer overflow with firmware-controlled content. Add a bounds check on the response length.

Affected products

Linux
  • <88a240d86d3d64521f9194abe185ac71cc74d0bd
  • ==3.13
  • <cfc67aee0c83e7f5d43a1dad3e25c789e9cc1d92
  • =<6.6.*
  • <18813b90032bfaafb225906a4d2b51be4dfc02c3
  • =<*
  • <15545ee71301e82d26d9a31b407ed0019eb62a60
  • <dae9cadf0925f1cbfb71306d60490890df3870a6
  • =<6.18.*
  • <1b5d8a248c3afa640bcc99fa95abcd1e36f3ee18
  • =<6.12.*
  • <3.13
  • =<7.1.*
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH

In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_hashlimit: validate hashtable supports XT_HASHLIMIT_RATE_MATCH The XT_HASHLIMIT_RATE_MATCH flag mode changes the semantics of the dsthash_ent structure which represents an entry in the hashtable. There is a union area which uses a different layout to express the rate match mode. Update .checkentry path to validate the XT_HASHLIMIT_RATE_MATCH mode flag is requested by two or more different rules that refer to the same hashtable. Otherwise, uninitialized access to the burst field in the union is possible. Reject the use of the XT_HASHLIMIT_RATE_MATCH mode flag if set on by revision less than 3 too.

Affected products

Linux
  • <24683fea1f06bd3bd2707b99460e859bc6464c22
  • <06a76334243ccd875a981aa8bb46c0f931ef1e3b
  • <4.14
  • =<6.6.*
  • ==4.14
  • <d186f77d18bdfb252d401ff992ca3001a6a65a0f
  • =<*
  • <32ec8d4aba2cf22e12bdc28df8c4bd833c195fc0
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <305b63e1402267459fdabb183af4527f6799eebf
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
crypto: ccp - Check for page allocation failure correctly in TIO

In the Linux kernel, the following vulnerability has been resolved: crypto: ccp - Check for page allocation failure correctly in TIO Sashiko notes: > if __snp_alloc_firmware_pages() returns NULL under memory pressure, is it > safe to pass it directly to page_address()? > > On architectures without HASHED_PAGE_VIRTUAL, page_address(NULL) might > compute a deterministic but invalid, non-zero virtual address. The > subsequent if (tio_status) check would then evaluate to true, and > sev_tsm_init_locked() would dereference the invalid pointer. Indeed, page_address(NULL) will return non-NULL garbage here. Fix this by checking the page allocation itself for NULL, not the resulting virtual address.

Affected products

Linux
  • =<*
  • ==6.19
  • <a8d5370eef00eca132a292b1901c9914c817e385
  • =<7.1.*
  • <6.19
  • <17e1aae19a06d9f6da4b46d54fa2aeab77ec0c69
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
KVM: TDX: Reject concurrent change to CPUID entry count

In the Linux kernel, the following vulnerability has been resolved: KVM: TDX: Reject concurrent change to CPUID entry count Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the initial read and the subsequent copy of the initialization data. tdx_td_init() first reads user_data->cpuid.nent to size the flexible kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent, and that field can differ from the value used to size the allocation if userspace modifies the input concurrently. setup_tdparams_cpuids() later passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as the array bound for the copied entries. Require the copied count to match the value used to size the allocation so that CPUID parsing cannot access beyond the entries actually copied.

Affected products

Linux
  • <d6b5aba65e99531c97b146622a406c75653819d5
  • =<*
  • ==6.19
  • <cfbebb55e5127dc162e73fa8956000055a78606c
  • =<7.1.*
  • <6.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Bluetooth: 6lowpan: avoid untracked enable work

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: 6lowpan: avoid untracked enable work lowpan_enable_set() allocates a temporary work item and schedules do_enable_set() on system_wq, then returns to debugfs. The debugfs active operation has ended at that point, but the worker still executes module text and manipulates enable_6lowpan and listen_chan. bt_6lowpan_exit() removes the debugfs files and immediately closes and puts listen_chan. It has no pointer to the queued work item, so it cannot cancel or flush it before tearing down the state that the worker uses. The buggy scenario involves two paths, with each column showing the order within that path: debugfs enable write module exit 1. lowpan_enable_set() allocates 1. bt_6lowpan_exit() removes set_enable work the debugfs file 2. schedule_work() queues 2. bt_6lowpan_exit() closes do_enable_set() and puts listen_chan 3. the write operation returns 3. module teardown can continue 4. do_enable_set() later runs against stale state Run the enable state transition synchronously in lowpan_enable_set() instead. The simple debugfs setter can sleep, and this file already handles the 6LoWPAN control write synchronously under the same set_lock. Once the setter returns, debugfs removal covers the whole operation and exit can no longer race with an untracked work item. Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in do_enable_set+0x113/0x2e0 Workqueue: events do_enable_set [bluetooth_6lowpan] The buggy address belongs to the object at ffff888109cb8000

Affected products

Linux
  • ==3.19
  • =<*
  • <352a59dc1f4a41314b6f827c17e16af7ca88271a
  • <feb3fc2c38ed52003142f31e04109719b200c049
  • =<7.1.*
  • <3.19
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 3 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister()

In the Linux kernel, the following vulnerability has been resolved: net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister() syzbot reported a memory leak [1] in the UDP tunnel NIC offload code. When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early: if (utn->work_pending) return; Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently. Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn. To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock. The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work. [1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96): comm "syz-executor", pid 5806, jiffies 4294942188 backtrace (crc 99fdb6c8): __kmalloc_noprof+0x3bf/0x550 udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline] udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline] udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931 notifier_call_chain+0x59/0x160 kernel/notifier.c:85 call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250 register_netdevice+0xc10/0xeb0 net/core/dev.c:11478

Affected products

Linux
  • ==5.9
  • =<*
  • <5.9
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <f82a2ded3d7a9098267c84f14eafdb98c4550ac5
  • <080695e6f005e2396f1207fd69d24c442cb230c6
  • <b712da45bd9b9835d132e9fbc0c3e43c164cb1fd
  • <b322532a4b774db1b480a2de84125910a70739a5