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
drm/msm: Fix VM_BIND UNMAP locking

In the Linux kernel, the following vulnerability has been resolved: drm/msm: Fix VM_BIND UNMAP locking Wrong argument meant that the objs involved in UNMAP ops were not always getting locked. Since _NO_SHARE objs share a common resv with the VM (which is always locked) this would only show up with non-_NO_SHARE BOs. Patchwork: https://patchwork.freedesktop.org/patch/713898/

Affected products

Linux
  • ==6.17
  • =<6.18.*
  • =<7.0.*
  • <85042c2cd970a6b0e686329387096fe19989ae62
  • <206f812ef140727b75697111391ae320fd8aa652
  • =<*
  • <d9ecf758270501b2e7a0bc1dd69a6f28f1ae3cae
  • <6.17
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/komeda: fix integer overflow in AFBC framebuffer size check

In the Linux kernel, the following vulnerability has been resolved: drm/komeda: fix integer overflow in AFBC framebuffer size check The AFBC framebuffer size validation calculates the minimum required buffer size by adding the AFBC payload size to the framebuffer offset. This addition is performed without checking for integer overflow. If the addition oveflows, the size check may incorrectly succed and allow userspace to provide an undersized drm_gem_object, potentially leading to out-of-bounds memory access. Add usage of check_add_overflow() to safely compute the minimum required size and reject the framebuffer if an overflow is detected. This makes the AFBC size validation more robust against malformed. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Affected products

Linux
  • <8165e8b28fdf392c2c7412518d602b4f193812a8
  • =<6.1.*
  • =<5.15.*
  • <e27b58095d7d3ac72f230e318838dee956258460
  • <fe1f80f8f6e8611ac6349b9d464e8750443390cf
  • =<6.18.*
  • =<6.12.*
  • =<7.0.*
  • <5.3
  • <a3a2a9bdc0f9c2d863a5a290cb2d4a565f7268e7
  • <d8a541906860aa3519b1874780d933c766918a7c
  • =<*
  • =<6.6.*
  • =<5.10.*
  • ==5.3
  • <02ff8a7d3d0eecc546b9ab4c07b3d7c65d485583
  • <872d923b852705054bc099af663da862fdc1097d
  • <779ec12c85c9e4547519e3903a371a3b26a289de
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: psp: check for device unregister when creating assoc

In the Linux kernel, the following vulnerability has been resolved: net: psp: check for device unregister when creating assoc psp_assoc_device_get_locked() obtains a psp_dev reference via psp_dev_get_for_sock() (which uses psp_dev_tryget() under RCU); it then acquires psd->lock and drops the reference. Before the lock is taken, psp_dev_unregister() can run to completion: take psd->lock, clear out state, unlock, drop the registration reference. The expectation is that the lock prevents device unregistration, but much like with netdevs special care has to be taken when "upgrading" a reference to a locked device. Add the missing check if device is still alive. psp_dev_is_registered() exists already but had no callers, which makes me wonder if I either forgot to add this or lost the check during refactoring...

Affected products

Linux
  • =<6.18.*
  • <d90df5ce6deb2424de3ad89bcc693ac1b67accc9
  • =<7.0.*
  • <b89769f936a8fa9e66de72ddc1b71a9745a488e6
  • ==6.18
  • =<*
  • <6.18
  • <e201c57073e624dd2ba5beaf9eda31e19b77b332
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: ath11k: fix memory leaks in beacon template setup

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix memory leaks in beacon template setup The functions ath11k_mac_setup_bcn_tmpl_ema() and ath11k_mac_setup_bcn_tmpl_mbssid() allocate memory for beacon templates but fail to free it when parameter setup returns an error. Since beacon templates must be released during normal execution, they must also be released in the error handling paths to prevent memory leaks. Fix this by using unified exit paths with proper cleanup in the respective error paths. Compile tested only. Issue found using a prototype static analysis tool and code review.

Affected products

Linux
  • <6.5
  • =<7.0.*
  • <5d63aa38d5ca85206d9699ffdd616b58780dba07
  • <ff49eba595df500e4ddccc593088c8a4ab5f2c27
  • =<*
  • ==6.5
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
futex: Drop CLONE_THREAD requirement for private default hash alloc

In the Linux kernel, the following vulnerability has been resolved: futex: Drop CLONE_THREAD requirement for private default hash alloc Currently need_futex_hash_allocate_default() depends on strict pthread semantics, abusing CLONE_THREAD. This breaks the non-concurrency assumptions when doing the mm->futex_ref pcpu allocations, leading to bugs[0] when sharing the mm in other ways; ie: BUG: KASAN: slab-use-after-free in futex_hash_put ... where the +1 bias can end up on a percpu counter that mm->futex_ref no longer points at. Loosen the check to cover any CLONE_VM clone, except vfork(). Excluding vfork keeps the existing paths untouched (no overhead), and we can't race in the first place: either the parent is suspended and the child runs alone, or mm->futex_ref is already allocated from an earlier CLONE_VM.

Affected products

Linux
  • <1dcd36420af2da5bd59306dba9caf78e3d248b1d
  • <6.17
  • =<6.18.*
  • =<7.0.*
  • =<*
  • <ee9dce44362b2d8132c32964656ab6dff7dfbc6a
  • ==6.17
  • <974ac49a9a068b0591a59f65c63eb06579a13091
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
powerpc/64s: Fix unmap race with PMD migration entries

In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix unmap race with PMD migration entries The following race is possible with migration swap entries or device-private THP entries. e.g. when move_pages is called on a PMD THP page, then there maybe an intermediate state, where PMD entry acts as a migration swap entry (pmd_present() is true). Then if an munmap happens at the same time, then this VM_BUG_ON() can happen in pmdp_huge_get_and_clear_full(). This patch fixes that. Thread A: move_pages() syscall add_folio_for_migration() mmap_read_lock(mm) folio_isolate_lru(folio) mmap_read_unlock(mm) do_move_pages_to_node() migrate_pages() try_to_migrate_one() spin_lock(ptl) set_pmd_migration_entry() pmdp_invalidate() # PMD: _PAGE_INVALID | _PAGE_PTE | pfn set_pmd_at() # PMD: migration swap entry (pmd_present=0) spin_unlock(ptl) [page copy phase] # <--- RACE WINDOW --> Thread B: munmap() mmap_write_downgrade(mm) unmap_vmas() -> zap_pmd_range() zap_huge_pmd() __pmd_trans_huge_lock() pmd_is_huge(): # !pmd_present && !pmd_none -> TRUE (swap entry) pmd_lock() -> # spin_lock(ptl), waits for Thread A to release ptl pmdp_huge_get_and_clear_full() VM_BUG_ON(!pmd_present(*pmdp)) # HITS! [ 287.738700][ T1867] ------------[ cut here ]------------ [ 287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187! cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0] pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c lr: c000000000645dec: zap_huge_pmd+0xb0/0x868 sp: c00000044037f790 msr: 800000000282b033 current = 0xc0000004032c1a00 paca = 0xc000000004fe0000 irqmask: 0x03 irq_happened: 0x09 pid = 1867, comm = a.out kernel BUG at :187! Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026 enter ? for help [link register ] c000000000645dec zap_huge_pmd+0xb0/0x868 [c00000044037f790] c00000044037f7d0 (unreliable) [c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868 [c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40 [c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8 [c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128 [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310 [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238 [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8 [c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40 [c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350 [c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec ---- Exception: 3000 (System Call Vectored) at 0000000010064a2c SP (7fff9b1ee9c0) is in userspace 0:mon> zh commit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"), enabled migration for device-private PMD entries. Hence this is one other path where this warning could get trigger from. ------------[ cut here ]------------ WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905 Modules linked in: test_hmm CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G B W L N 7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284 LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4 Call Trace: [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable) [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498 [c000000604707760] [c00000000063e5a4] migrate_vma_col ---truncated---

Affected products

Linux
  • <5.8
  • =<7.0.*
  • =<*
  • ==5.8
  • <829367e55012c053738ebe7db20c4a90d6609ece
  • <bbcbf045d6c778e82b47a35fc8728387708e9a3d
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit()

In the Linux kernel, the following vulnerability has been resolved: net: usb: rtl8150: fix use-after-free in rtl8150_start_xmit() syzbot reported a KASAN slab-use-after-free read in rtl8150_start_xmit() when accessing skb->len for tx statistics after usb_submit_urb() has been called: BUG: KASAN: slab-use-after-free in rtl8150_start_xmit+0x71f/0x760 drivers/net/usb/rtl8150.c:712 Read of size 4 at addr ffff88810eb7a930 by task kworker/0:4/5226 The URB completion handler write_bulk_callback() frees the skb via dev_kfree_skb_irq(dev->tx_skb). The URB may complete on another CPU in softirq context before usb_submit_urb() returns in the submitter, so by the time the submitter reads skb->len the skb has already been queued to the per-CPU completion_queue and freed by net_tx_action(): CPU A (xmit) CPU B (USB completion softirq) ------------ ------------------------------ dev->tx_skb = skb; usb_submit_urb() --+ |-------> write_bulk_callback() | dev_kfree_skb_irq(dev->tx_skb) | net_tx_action() | napi_skb_cache_put() <-- free netdev->stats.tx_bytes | += skb->len; <-- UAF read Fix it by caching skb->len before submitting the URB and using the cached value when updating the tx_bytes counter. The pre-existing tx_bytes semantics are preserved: the counter tracks the original frame length (skb->len), not the ETH_ZLEN/USB-alignment padded "count" value that is handed to the device. Changing that would be a user-visible accounting change and is out of scope for this UAF fix.

Affected products

Linux
  • <23f0e34c64acba15cad4d23e50f41f533da195fa
  • <4dd7eb94f79486b77ca6b4c8676aedbc465dc802
  • =<5.15.*
  • =<6.18.*
  • <5af290c86fa81ddbc86a08d54229af5daa40c6a4
  • =<6.12.*
  • =<7.0.*
  • <30cf9829d09ca958279c937af8e35495cd2f1e09
  • <423b5b86e14e190f6e3161eb5f2ea5f908295ba7
  • <6999d70e0eda39af029fa1891c48f0a8832b09d5
  • <2.6.12
  • ==2.6.12
  • =<*
  • =<5.10.*
  • =<6.1.*
  • <5db090ca07b28a63fb1499690cf19a3f3adafacb
  • <24831b0b2ada9fef18d1f486b7b7c444ee5ba637
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ublk: reset per-IO canceled flag on each fetch

In the Linux kernel, the following vulnerability has been resolved: ublk: reset per-IO canceled flag on each fetch If a ublk server starts recovering devices but dies before issuing fetch commands for all IOs, cancellation of the fetch commands that were successfully issued may never complete. This is because the per-IO canceled flag can remain set even after the fetch for that IO has been submitted - the per-IO canceled flags for all IOs in a queue are reset together only once all IOs for that queue have been fetched. So if a nonempty proper subset of the IOs for a queue are fetched when the ublk server dies, the IOs in that subset will never successfully be canceled, as their canceled flags remain set, and this prevents ublk_cancel_cmd from actually calling io_uring_cmd_done on the commands, despite the fact that they are outstanding. Fix this by resetting the per-IO cancel flags immediately when each IO is fetched instead of waiting for all IOs for the queue (which may never happen).

Affected products

Linux
  • <6.15
  • =<7.0.*
  • <63335e5a67d89bb7cb9b023bbb3785896587a648
  • ==6.15
  • <0842186d2c4e67d2f8c8c2d1d779e8acffd41b5b
  • =<*
  • <6.15
  • ==42ea64e01c96e594fb4f80c54dfe4f934d008a6e
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl

In the Linux kernel, the following vulnerability has been resolved: i2c: dev: prevent integer overflow in I2C_TIMEOUT ioctl While fuzzing with Syzkaller, a persistent `schedule_timeout: wrong timeout value` warning was observed, accompanied by SMBus controller state machine corruption. The I2C_TIMEOUT ioctl accepts a user-provided timeout in multiples of 10 ms. The user argument is checked against INT_MAX, but it is subsequently multiplied by 10 before being passed to msecs_to_jiffies(). A malicious user can pass a large value (e.g., 429496729) that passes the `arg > INT_MAX` check but overflows when multiplied by 10. This results in a truncated 32-bit unsigned value that bypasses the internal `(int)m < 0` check in `msecs_to_jiffies()`. The truncated value is then assigned to `client->adapter->timeout` (a signed 32-bit int), which is reinterpreted as a negative number. When passed to wait_for_completion_timeout(), this negative value undergoes sign extension to a 64-bit unsigned long, triggering the `schedule_timeout` warning and causing premature returns. This leaves the SMBus state machine in an unrecoverable state, constituting a local Denial of Service (DoS). Fix this by bounding the user argument to `INT_MAX / 10`. [wsa: move the comment as well]

Affected products

Linux
  • <ffbcf31f032eb454ebfd29309f51366fe57f4ac4
  • =<6.18.*
  • <7.0.13
  • =<7.0.*
  • <e9ffd5f5050fbb199d270a85614cd27ebed6fbac
  • <6.18.36
  • =<6.1.*
  • <617eb7c0961a8dfcfc811844a6396e406b2923ea
  • <6.6.143
  • <5.10.259
  • <0b88ecfbc9dc33b4db8836c37b50cf174e6c0691
  • <6.12.94
  • <aa6ef734016912653a909477fb30aeb66c98b3a2
  • <5.15.210
  • =<5.15.*
  • <ff02add34ffd03449b8115904ebe2ec4fed022d4
  • <4576621dc6577f21a032acfd16c3ad61907a5ea7
  • <943e318eedbeaeea08ece3f5dd44c982f4ed2ef5
  • =<*
  • <6.1.176
  • =<6.12.*
  • =<5.10.*
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 5 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
batman-adv: tp_meter: avoid use of uninit sender vars

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tp_meter: avoid use of uninit sender vars batadv_tp_recv_ack() and batadv_tp_stop() are only valid for tp_vars in the BATADV_TP_SENDER role. When called with a BATADV_TP_RECEIVER role, it proceeds to read sender-only members that were never initialized, leading to undefined behavior. This can be triggered when a node that is currently acting as a receiver in an ongoing tp_meter session receives a malicious ACK packet. Guard against this by checking tp_vars->role immediately after the lookup and bailing out if it is not BATADV_TP_SENDER, before any of those members are accessed.

Affected products

Linux
  • =<5.15.*
  • =<6.18.*
  • <6c65cf23d4c6170fcf5714c32aa64689718cb142
  • <53f931e0146ae5bdab4cba302646827d06b3794b
  • ==4.8
  • =<6.12.*
  • =<5.10.*
  • =<7.0.*
  • <dc2ae5fbd2dadc26735092f140b246841d969a11
  • =<*
  • <9884c9c02d3c90e9215db3c5128f59045d20ae91
  • <ecdaa3e4d91040206afe21bc8a0d1198a0971ff3
  • <1a21c055f66e78973712a4a1be2a554f1ee2e4f4
  • <0e388af04b3958b178a1b979527f93eb46ea1fee
  • <4.8
  • =<6.1.*
  • <85397e48afe6be83ffca5ad3f4792296bfc81d3d
  • =<6.6.*