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 ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ipv6: fix possible UAF in icmpv6_rcv()

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix possible UAF in icmpv6_rcv() Caching saddr and daddr before pskb_pull() is problematic since skb->head can change. Remove these temporary variables: - We only access &ipv6_hdr(skb)->saddr and &ipv6_hdr(skb)->daddr when net_dbg_ratelimited() is called in the slow path. - Avoid potential future misuse after pskb_pull() call.

Affected products

Linux
  • <1e1f0f89ee4692a64be3f3707ff8ac1ae57b03e7
  • =<6.1.*
  • =<*
  • <f996edd7615e686ada141b7f3395025729ff8ccb
  • =<5.15.*
  • <4.4
  • =<5.10.*
  • <085e31a811ef234ef8c3e219c4636dfebfe7e10f
  • =<6.18.*
  • <38bdbc897c0d83a3e2b925a51b69420f1feba29a
  • <aff0f28f5be803de2452ce702631c021fcd9ce8a
  • <7c66b368c6ff453f99cb39d84af93e908e51eef2
  • =<6.6.*
  • =<6.12.*
  • <7bff2c8fe5c35ae58bf73104f53db3676e6e5d94
  • =<7.0.*
  • ==4.4
  • <0069813e6ca9309eca78022bcb3aeb1e9ef90a12
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check

In the Linux kernel, the following vulnerability has been resolved: netfilter: nfnetlink_osf: fix potential NULL dereference in ttl check The nf_osf_ttl() function accessed skb->dev to perform a local interface address lookup without verifying that the device pointer was valid. Additionally, the implementation utilized an in_dev_for_each_ifa_rcu loop to match the packet source address against local interface addresses. It assumed that packets from the same subnet should not see a decrement on the initial TTL. A packet might appear it is from the same subnet but it actually isn't especially in modern environments with containers and virtual switching. Remove the device dereference and interface loop. Replace the logic with a switch statement that evaluates the TTL according to the ttl_check.

Affected products

Linux
  • <711987ba281fd806322a7cd244e98e2a81903114
  • <2.6.31
  • =<6.1.*
  • <f4de0777e4554a7de19c920accde6319dd530782
  • =<*
  • <83fc5dd63455a779ea2dd0f7ffee3c920919d80b
  • =<5.15.*
  • <79b90a96688e521771fa6ed3dc7864b76b8df293
  • =<5.10.*
  • ==2.6.31
  • <edc806f9122961f0d3819f7c69c14cccde31f277
  • =<6.18.*
  • <5d05de2f0928d81309a815ecc76d1a3ad72cbc16
  • =<6.6.*
  • =<6.12.*
  • =<7.0.*
  • <95be653a76793856ff8b2d8bd82c2943c23f5ca8
  • <c996a90f3071cf43683e5423da31aadbe002b8b4
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal

In the Linux kernel, the following vulnerability has been resolved: fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls `fwctl_register()` and then `device_add()`, fwctl_class is not yet registered because fwctl_init() hasn't run, causing `class_to_subsys()` to return NULL and skip knode_class initialization. On device removal, `class_to_subsys()` returns non-NULL, and `device_del()` calls `klist_del()` on the uninitialized knode, triggering a NULL pointer dereference.

Affected products

Linux
  • =<*
  • ==6.15
  • =<6.18.*
  • <a55f80233f384dc89ef3425b2e1dd0e6d44bcf29
  • <6.15
  • <1075f2f590fdac147f8b8010c35b606564b5c7d7
  • =<7.0.*
  • <a28f56988c8e5bb9375806a5cfb0bf54d662ae3f
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ppp: require CAP_NET_ADMIN in target netns for unattached ioctls

In the Linux kernel, the following vulnerability has been resolved: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls /dev/ppp open is currently authorized against file->f_cred->user_ns, while unattached administrative ioctls operate on current->nsproxy->net_ns. As a result, a local unprivileged user can create a new user namespace with CLONE_NEWUSER, gain CAP_NET_ADMIN only in that new user namespace, and still issue PPPIOCNEWUNIT, PPPIOCATTACH, or PPPIOCATTCHAN against an inherited network namespace. Require CAP_NET_ADMIN in the user namespace that owns the target network namespace before handling unattached PPP administrative ioctls. This preserves normal pppd operation in the network namespace it is actually privileged in, while rejecting the userns-only inherited-netns case.

Affected products

Linux
  • <5080e188c914110034bbc569d5cfa2f06204681d
  • <954745d0223e7caec917c0b2d1a889ff56fa6e54
  • <3b2c2157dc2afc5c17cd7238afefca92f1ef330e
  • <1a8a51ce85075a56a743b6f142606dd2696a391c
  • =<6.1.*
  • =<*
  • =<5.15.*
  • =<5.10.*
  • =<6.18.*
  • ==2.6.30
  • =<7.0.*
  • =<6.6.*
  • =<6.12.*
  • <2bb6379416fd19f44c3423a00bfd8626259f6067
  • <5013be175c7ffd8b39efbc3c9c4db5b10b85fea8
  • <c9edd90c57ae23692fff6b049fdfa4572a9fd532
  • <2.6.30
  • <67e901e28d177ac9a9bed76d69ce3471e704a89e
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI 2.0 endpoint descriptor scans The USB MIDI 2.0 endpoint parser has the same descriptor walking pattern as the legacy MIDI parser. It validates bLength against bNumGrpTrmBlock before reading baAssoGrpTrmBlkID[], but not against the remaining bytes in the endpoint-extra scan. A malformed device can therefore make later baAssoGrpTrmBlkID[] reads consume bytes past the walked descriptor. Reject zero-length and overlong descriptors while walking endpoint extras.

Affected products

Linux
  • =<*
  • <918be519c7876329e1b6e2ea1c59f0b75e792dca
  • =<6.18.*
  • ==6.5
  • <f9c184a83574549a36ea69b755f650e57d164c78
  • =<7.0.*
  • <fafc97bd01e4c737eaeafadfdadb1af4bbfa7307
  • =<6.6.*
  • <6.5
  • <17e76b19de1aff5ff4de64d269290bd1b07a01d3
  • =<6.12.*
  • <a310b4bebda5e4a1b26520c0cc5145ccd6d617e2
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf

In the Linux kernel, the following vulnerability has been resolved: net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf sixpack_receive_buf() does not properly skip bytes with TTY error flags. The while loop iterates through the flags buffer but never advances the data pointer (cp), and passes the original count (including error bytes) to sixpack_decode(). This causes sixpack_decode() to process bytes that should have been skipped due to TTY errors. The TTY layer does not guarantee that cp[i] holds a meaningful value when fp[i] is set, so passing those positions to sixpack_decode() results in KMSAN reporting an uninit-value read. Fix this by processing bytes one at a time, advancing cp on each iteration, and only passing valid (non-error) bytes to sixpack_decode(). This matches the pattern used by slip_receive_buf() and mkiss_receive_buf() for the same purpose.

Affected products

Linux
  • <bf9a38803b2626b01cc769aaf13485d8650f576f
  • <578f3aba427c938fecfa0d8c83d9acb213a9b24a
  • <e9cf4018d74237d142cd66243c821d13593270f0
  • =<6.18.*
  • <2.6.12
  • <d4cceb5184538613572fb79319453f281b1eeacb
  • ==2.6.12
  • =<5.10.*
  • <2951656b0de00153f2687f3a093890bce72b6215
  • <1d3abf0c3ddeefc6f6d913aa129acc06fce8240a
  • <987af7625ceb1ee59d70eb0abd7af11c75e45d79
  • =<5.15.*
  • =<6.1.*
  • =<6.12.*
  • =<7.0.*
  • =<*
  • =<6.6.*
  • <d9ce2a4b679122397d7f35bad7be46913ad1ca80
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: fix deadlock in remain-on-channel

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: fix deadlock in remain-on-channel mt76_remain_on_channel() and mt76_roc_complete() call mt76_set_channel() while already holding dev->mutex. Since mt76_set_channel() also acquires dev->mutex, this results in a deadlock. Use __mt76_set_channel() instead of mt76_set_channel(). Add cancel_delayed_work_sync() for mac_work before acquiring the mutex in mt76_remain_on_channel() to prevent a secondary deadlock with the mac_work workqueue.

Affected products

Linux
  • <6939b97ddad3cf3dfbb3b5a0a12ef79cb886747e
  • <5fc8c5d45e44575dda9fcabdc2aac4ad97baf0cd
  • <6.14
  • =<7.0.*
  • =<*
  • =<6.18.*
  • <7a89c245d203aa0ed5ff2d68ac05b48b2ef9fa3f
  • ==6.14
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ipc/shm: serialize orphan cleanup with shm_nattch updates

In the Linux kernel, the following vulnerability has been resolved: ipc/shm: serialize orphan cleanup with shm_nattch updates shm_destroy_orphaned() walks the shm idr under shm_ids(ns).rwsem, but that does not serialize all fields tested by shm_may_destroy(). In particular, shm_nattch is updated while holding shm_perm.lock, and attach paths can do that without holding the rwsem. Do not decide that an orphaned segment is unused before taking the object lock. Move the shm_may_destroy() check under shm_perm.lock, matching the other destroy paths, and unlock the segment when it no longer qualifies for removal.

Affected products

Linux
  • <2e5c6f4fd4001562781e99bbfc7f1f0127187542
  • <1f0d01e35dbb228084d5187212e32c91a30dcbeb
  • =<6.1.*
  • =<*
  • <030bbc857bd51d4b25a90d931d3f8775ef22823a
  • =<5.15.*
  • =<5.10.*
  • ==3.1
  • =<6.18.*
  • =<7.0.*
  • =<6.6.*
  • =<6.12.*
  • <db752ebfdaf2c7f27cd9690ef48b616af068319c
  • <3.1
  • <6560be3f6a5bb84f006f184f0c966747bb58e1a3
  • <92cda2593cf2ed25b0e9d78e5e6d8303bba1a064
  • <b5107b4ce3ad45fcf369ee2058c8910620f4b5a8
  • <b1e9aef48e4d8a0c1b54fb913077b0824ed7d650
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling

In the Linux kernel, the following vulnerability has been resolved: fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal. When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ) The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting. Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets. Lockdep splat: ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); <Interrupt> lock(&dev->event_lock); *** DEADLOCK ***

Affected products

Linux
  • <7.0.13
  • <1bee417678f1135e35b25a37734db46aa94258d2
  • =<5.10.*
  • <32dbd5ce4be3a3ed7e00f8af18795cc84fc50a33
  • =<6.12.*
  • <36c1b57b2ecf3c61ac93f5f07bd29b6f21e226ed
  • =<6.1.*
  • <5.10.259
  • <20a93e397abe850c49b6fa0e8cc827b5f634a8f5
  • =<6.6.*
  • <7.1.1
  • <bfcc8e8d8a495bb34cae9e620adfb75fb13a3954
  • <6.6.143
  • <5.15.210
  • =<7.1.*
  • <6.1.176
  • <897d6a7247739fb1528f98c575df4f2e5de7f994
  • <b5fa9e32fb6718f70c986ee14dd5d01b4846f331
  • <6.12.94
  • <54626335ea4174ab2d9a183b511d825f6765e47b
  • =<5.15.*
  • =<6.18.*
  • =<7.0.*
  • <6.18.36
Dismissed
(max. allowed matches exceeded)
created 2 months ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy

In the Linux kernel, the following vulnerability has been resolved: powerpc/pgtable-frag: Fix bad page state in pte_frag_destroy powerpc uses pt_frag_refcount as a reference counter for tracking it's pte and pmd page table fragments. For PTE table, in case of Hash with 64K pagesize, we have 16 fragments of 4K size in one 64K page. Patch series [1] "mm: free retracted page table by RCU" added pte_free_defer() to defer the freeing of PTE tables when retract_page_tables() is called for madvise MADV_COLLAPSE on shmem range. [1]: https://lore.kernel.org/all/7cd843a9-aa80-14f-5eb2-33427363c20@google.com/ pte_free_defer() sets the active flag on the corresponding fragment's folio & calls pte_fragment_free(), which reduces the pt_frag_refcount. When pt_frag_refcount reaches 0 (no active fragment using the folio), it checks if the folio active flag is set, if set, it calls call_rcu to free the folio, it the active flag is unset then it calls pte_free_now(). Now, this can lead to following problem in a corner case... [ 265.351553][ T183] BUG: Bad page state in process a.out pfn:20d62 [ 265.353555][ T183] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20d62 [ 265.355457][ T183] flags: 0x3ffff800000100(active|node=0|zone=0|lastcpupid=0x7ffff) [ 265.358719][ T183] raw: 003ffff800000100 0000000000000000 5deadbeef0000122 0000000000000000 [ 265.360177][ T183] raw: 0000000000000000 c0000000119caf58 00000000ffffffff 0000000000000000 [ 265.361438][ T183] page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set [ 265.362572][ T183] Modules linked in: [ 265.364622][ T183] CPU: 0 UID: 0 PID: 183 Comm: a.out Not tainted 6.18.0-rc3-00141-g1ddeaaace7ff-dirty #53 VOLUNTARY [ 265.364785][ T183] Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries [ 265.364908][ T183] Call Trace: [ 265.364955][ T183] [c000000011e6f7c0] [c000000001cfaa18] dump_stack_lvl+0x130/0x148 (unreliable) [ 265.365202][ T183] [c000000011e6f7f0] [c000000000794758] bad_page+0xb4/0x1c8 [ 265.365384][ T183] [c000000011e6f890] [c00000000079c020] __free_frozen_pages+0x838/0xd08 [ 265.365554][ T183] [c000000011e6f980] [c0000000000a70ac] pte_frag_destroy+0x298/0x310 [ 265.365729][ T183] [c000000011e6fa30] [c0000000000aa764] arch_exit_mmap+0x34/0x218 [ 265.365912][ T183] [c000000011e6fa80] [c000000000751698] exit_mmap+0xb8/0x820 [ 265.366080][ T183] [c000000011e6fc30] [c0000000001b1258] __mmput+0x98/0x300 [ 265.366244][ T183] [c000000011e6fc80] [c0000000001c81f8] do_exit+0x470/0x1508 [ 265.366421][ T183] [c000000011e6fd70] [c0000000001c95e4] do_group_exit+0x88/0x148 [ 265.366602][ T183] [c000000011e6fdc0] [c0000000001c96ec] pid_child_should_wake+0x0/0x178 [ 265.366780][ T183] [c000000011e6fdf0] [c00000000003a270] system_call_exception+0x1b0/0x4e0 [ 265.366958][ T183] [c000000011e6fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec The bad page state error occurs when such a folio gets freed (with active flag set), from do_exit() path in parallel. ... this can happen when the pte fragment was allocated from this folio, but when all the fragments get freed, the pte_frag_refcount still had some unused fragments. Now, if this process exits, with such folio as it's cached pte_frag in mm->context, then during pte_frag_destroy(), we simply call pagetable_dtor() and pagetable_free(), meaning it doesn't clear the active flag. This, can lead to the above bug. Since we are anyway in do_exit() path, then if the refcount is 0, then I guess it should be ok to simply clear the folio active flag before calling pagetable_dtor() & pagetable_free().

Affected products

Linux
  • ==6.6
  • =<6.18.*
  • <fda4d71651f71c44b35829d13f3c8bf920032f77
  • =<*
  • =<7.0.*
  • <6.6
  • <c8b710655012a2993a9567873fb71a8a51f8459c
  • <a32db6fca3c74b4eb8bae5470f0680deb4cbac6f