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
iommu/vt-d: Fix oops due to out of scope access

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix oops due to out of scope access Below oops triggers when kill QEMU process: Oops: general protection fault, probably for non-canonical address 0x7fffffff844eaaa7: 0000 [#1] SMP NOPTI Call Trace: <TASK> do_raw_spin_lock+0xaa/0xc0 _raw_spin_lock_irqsave+0x21/0x40 domain_remove_dev_pasid+0x52/0x160 intel_nested_set_dev_pasid+0x1b9/0x1e0 __iommu_set_group_pasid+0x56/0x120 pci_dev_reset_iommu_done+0xe3/0x180 pcie_flr+0x65/0x160 __pci_reset_function_locked+0x5b/0x120 vfio_pci_core_close_device+0x63/0xe0 [vfio_pci_core] vfio_df_close+0x4f/0xa0 vfio_df_unbind_iommufd+0x2d/0x60 vfio_device_fops_release+0x3e/0x40 __fput+0xe5/0x2c0 task_work_run+0x58/0xa0 do_exit+0x2c8/0x600 do_group_exit+0x2f/0xa0 get_signal+0x863/0x8c0 arch_do_signal_or_restart+0x24/0x100 exit_to_user_mode_loop+0x87/0x380 do_syscall_64+0x2ff/0x11e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e The global static blocked domain is a dummy domain without corresponding dmar_domain structure, accessing beyond iommu_domain structure triggers oops easily. Fix it by return early in domain_remove_dev_pasid() like identity domain.

Affected products

Linux
  • <6.6
  • <1e659db468476733d217c1314c1e0d9244356d6c
  • <a6dea58d8625c06b9654c0555f101742481335c3
  • =<6.18.*
  • =<7.0.*
  • <88397fad7914ee74a7880fa5ce01f9eb6bfe0743
  • ==6.6
  • =<*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
batman-adv: tvlv: reject oversized TVLV packets

In the Linux kernel, the following vulnerability has been resolved: batman-adv: tvlv: reject oversized TVLV packets batadv_tvlv_container_ogm_append() builds a TVLV packet section from the tvlv.container_list. The total size of this section is computed by batadv_tvlv_container_list_size(), which sums the sizes of all registered containers. The return type and accumulator in batadv_tvlv_container_list_size() were u16. If the accumulated size exceeds U16_MAX, the value wraps around, causing the subsequent allocation in batadv_tvlv_container_ogm_append() to be undersized. The memcpy-style copy that follows would then write beyond the end of the allocated buffer, corrupting kernel memory. Fix this by widening the return type of batadv_tvlv_container_list_size() to size_t. In batadv_tvlv_container_ogm_append(), check the computed length against U16_MAX before proceeding, and bail out as if the allocation had failed when the limit is exceeded.

Affected products

Linux
  • <94a3d72cd9b21116d7c6d5bdc57c11401fc28557
  • =<5.15.*
  • =<6.18.*
  • <ede47988ac5687793745b17c1634a496a2299919
  • <1595628a2f877d052eda18865ccf539392c47c04
  • <3.13
  • <f50487e3566358b2b982b7801945e858c78ad9ab
  • =<7.0.*
  • =<6.12.*
  • =<*
  • <94db72e9dac202e017ee3db22c59d17e4f3bf171
  • ==3.13
  • =<6.6.*
  • <c02aa6c0c9d1bea9bb75dea362b75ad225137bae
  • =<6.1.*
  • =<5.10.*
  • <6448a49344e87487b61bd88cb850cd694a0f576d
  • <13493b00dd1e05a705981e052158652ea23eb482
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work()

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix use-after-free bugs in mt7996_mac_dump_work() When the mt7996 pci chip is detaching, the mt7996_crash_data is released in mt7996_coredump_unregister(). However, the work item dump_work may still be running or pending, leading to UAF bugs when the already freed crash_data is dereferenced again in mt7996_mac_dump_work(). The race condition can occur as follows: CPU 0 (removal path) | CPU 1 (workqueue) mt7996_pci_remove() | mt7996_sys_recovery_set() mt7996_unregister_device() | mt7996_reset() mt7996_coredump_unregister() | queue_work() vfree(dev->coredump.crash_data) | mt7996_mac_dump_work() | crash_data-> // UAF Fix this by ensuring dump_work is properly canceled before the crash_data is deallocated. Add cancel_work_sync() in mt7996_unregister_device() to synchronize with any pending or executing dump work.

Affected products

Linux
  • <c8f62f73bbced3a79894655bdb0b625462d956fc
  • <aa4a31cd89f4fde5043ac613fe0e27014a60a60b
  • =<6.18.*
  • <188e10f9ea3109d23c6b7643aa6ec2f5cb0faa6d
  • =<7.0.*
  • <180182a3f23ff79430a32ca2c4c1885368ceab48
  • =<*
  • ==6.4
  • =<6.12.*
  • <6.4
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: skbuff: fix missing zerocopy reference in pskb_carve helpers

In the Linux kernel, the following vulnerability has been resolved: net: skbuff: fix missing zerocopy reference in pskb_carve helpers pskb_carve_inside_header() and pskb_carve_inside_nonlinear() both copy the old skb_shared_info header into a new buffer via memcpy(), which includes the destructor_arg pointer (uarg) for MSG_ZEROCOPY skbs. Neither function calls net_zcopy_get() for the new shinfo, creating an unaccounted holder: every skb_shared_info with destructor_arg set will call skb_zcopy_clear() once when freed, but the corresponding net_zcopy_get() was never called for the new copy. Repeated calls drive uarg->refcnt to zero prematurely, freeing ubuf_info_msgzc while TX skbs still hold live destructor_arg pointers. KASAN reports use-after-free on a freed ubuf_info_msgzc: BUG: KASAN: slab-use-after-free in skb_release_data+0x77b/0x810 Read of size 8 at addr ffff88801574d3e8 by task poc/220 Call Trace: skb_release_data+0x77b/0x810 kfree_skb_list_reason+0x13e/0x610 skb_release_data+0x4cd/0x810 sk_skb_reason_drop+0xf3/0x340 skb_queue_purge_reason+0x282/0x440 rds_tcp_inc_free+0x1e/0x30 rds_recvmsg+0x354/0x1780 __sys_recvmsg+0xdf/0x180 Allocated by task 219: msg_zerocopy_realloc+0x157/0x7b0 tcp_sendmsg_locked+0x2892/0x3ba0 Freed by task 219: ip_recv_error+0x74a/0xb10 tcp_recvmsg+0x475/0x530 The skb consuming the late access still referenced the same uarg via shinfo->destructor_arg copied by pskb_carve_inside_nonlinear() without a refcount bump. This has been verified to be reliably exploitable: a working proof-of-concept achieves full root privilege escalation from an unprivileged local user on a default kernel configuration. The fix follows the pattern of pskb_expand_head() which has the same memcpy/cloned structure. For pskb_carve_inside_header(), net_zcopy_get() is placed after skb_orphan_frags() succeeds, so the orphan error path needs no cleanup. For pskb_carve_inside_nonlinear(), net_zcopy_get() is placed after all failure points and just before skb_release_data(), so no error path needs cleanup at all -- matching pskb_expand_head() more closely and avoiding the need for a balancing net_zcopy_put().

Affected products

Linux
  • <ceafb893b12f23331dcc5ff9587e643c3a40ee9f
  • <96a4713ae041cc85e712bac682cd2e644004d6c6
  • =<6.1.*
  • =<5.15.*
  • =<6.18.*
  • <2e0e74c59b2761a414d9f48d7bee1e45220b2427
  • <98d0912e9f841e5529a5b89a972805f34cb1c69d
  • <8dbed691e43a50903658130bde0fcb5abc425b37
  • =<7.0.*
  • <fd470f0a97b8e9a125f520265d2f3b088ffb5b8a
  • <4.7
  • =<*
  • <474d6c771d798bca84f0a140b611e36743511e18
  • <9b40bdc2a3298225dffab8158208a0d8c6300578
  • =<6.12.*
  • =<5.10.*
  • ==4.7
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
fs/ntfs3: terminate the cached volume label after UTF-8 conversion

In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: terminate the cached volume label after UTF-8 conversion ntfs_fill_super() loads the on-disk volume label with utf16s_to_utf8s() and stores the result in sbi->volume.label. The converted label is later exposed through ntfs3_label_show() using %s, but utf16s_to_utf8s() only returns the number of bytes written and does not add a trailing NUL. If the converted label fills the entire fixed buffer, ntfs3_label_show() can read past the end of sbi->volume.label while looking for a terminator. Terminate the cached label explicitly after a successful conversion and clamp the exact-full case to the last byte of the buffer.

Affected products

Linux
  • =<6.6.*
  • =<5.15.*
  • =<6.18.*
  • <0b11fcbe80a59acdf58337d80ebb5f72201d73d6
  • =<6.12.*
  • =<7.0.*
  • <a6cd43fe9b083fa23fe1595666d5738856cb261a
  • <bc7a0c34c4ca259cfddf3bc18fc5b3c6411d26ed
  • <5.15
  • <6136bbb054f7ab9f51ae99915541633b18bcef90
  • =<*
  • <5cd0707b81cb4589f00aec5c4c1288bd0980d2a4
  • <32b0686369e0afbb3549a0d93e2d8517da84cd30
  • =<6.1.*
  • ==5.15
  • <54d564b762389679e2f8fb9eeb20af7e82371e1c
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
bpf: Fix NULL deref in map_kptr_match_type for scalar regs

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix NULL deref in map_kptr_match_type for scalar regs Commit ab6c637ad027 ("bpf: Fix a bpf_kptr_xchg() issue with local kptr") refactored map_kptr_match_type() to branch on btf_is_kernel() before checking base_type(). A scalar register stored into a kptr slot has no btf, so the btf_is_kernel(reg->btf) call dereferences NULL. Move the base_type() != PTR_TO_BTF_ID guard before any reg->btf access.

Affected products

Linux
  • <6.6
  • <520454e839710c327808c2fcc98e28cee77355fc
  • =<6.18.*
  • ==4782968e0d631b0d8944dcfd4bf8fb49be087101
  • =<6.12.*
  • ==af3d2e0f3a54e67806959d161e613457772babc5
  • =<7.0.*
  • <6982653ce5f119982aa58f1af58e7bfbebf39252
  • <4d0a375887ab4d49e4da1ff10f9606cab8f7c3ad
  • ==6.6
  • =<*
  • <da1d615ce49a47986a8864e2371a26e97861085c
  • <0a36c1f72888bca0237295a4da19cd91821a90be
  • =<6.6.*
  • <6.5
  • <6.6
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepoint

In the Linux kernel, the following vulnerability has been resolved: net/smc: avoid NULL deref of conn->lnk in smc_msg_event tracepoint The smc_msg_event tracepoint class, shared by smc_tx_sendmsg and smc_rx_recvmsg, unconditionally dereferences smc->conn.lnk: __string(name, smc->conn.lnk->ibname) conn->lnk is only set for SMC-R; for SMC-D it is NULL. Other code on these paths already handles this (e.g. !conn->lnk in SMC_STAT_RMB_TX_SIZE_SMALL()). With the tracepoint enabled, the first sendmsg()/recvmsg() on an SMC-D socket crashes: Oops: general protection fault, probably for non-canonical address KASAN: null-ptr-deref in range [...] RIP: 0010:strlen+0x1e/0xa0 Call Trace: trace_event_raw_event_smc_msg_event (net/smc/smc_tracepoint.h:44) smc_rx_recvmsg (net/smc/smc_rx.c:515) smc_recvmsg (net/smc/af_smc.c:2859) __sys_recvfrom (net/socket.c:2315) __x64_sys_recvfrom (net/socket.c:2326) do_syscall_64 The faulting address 0x3e0 is offsetof(struct smc_link, ibname), confirming the NULL ->lnk deref. Enabling the tracepoint requires root, but the trigger itself is unprivileged: socket(AF_SMC, ...) has no capability check, and SMC-D negotiation needs no admin step on s390 or on x86 with the loopback ISM device loaded. Log an empty device name for SMC-D instead of dereferencing NULL.

Affected products

Linux
  • <720c76b930c52cd58f50eb6b10569d03dccc7959
  • =<6.1.*
  • =<6.18.*
  • ==5.16
  • =<6.12.*
  • =<7.0.*
  • =<*
  • <561cf66fa9b6c86dfe4e687d2d1aeaaa6739917f
  • <68200112534bb2acd1d7117dc2d5c124868d866d
  • =<6.6.*
  • <7bf563badd37cb796df5477d2b78bb64148a1268
  • <b706d6d76a2a2793fe5ad0fbc2a75b6a460094ef
  • <5.16
  • <d2ea0b8aef8746e147602eac87ca8538f4bc7e66
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change()

In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_dualpi2: drain both C-queue and L-queue in dualpi2_change() Fix dualpi2_change() to correctly enforce updated limit and memlimit values after a configuration change of the dualpi2 qdisc. Before this patch, dualpi2_change() always attempted to dequeue packets via the root qdisc (C-queue) when reducing backlog or memory usage, and unconditionally assumed that a valid skb will be returned. When traffic classification results in packets being queued in the L-queue while the C-queue is empty, this leads to a NULL skb dereference during limit or memlimit enforcement. This is fixed by first dequeuing from the C-queue path if it is non-empty. Once the C-queue is empty, packets are dequeued directly from the L-queue. Return values from qdisc_dequeue_internal() are checked for both queues. When dequeuing from the L-queue, the parent qdisc qlen and backlog counters are updated explicitly to keep overall qdisc statistics consistent.

Affected products

Linux
  • <478ed6b7d2577439c610f91fa8759a4c878a4264
  • <6.17
  • =<6.18.*
  • =<7.0.*
  • <86cf2eba2056bcf9c41fba260e599bd95bf9943b
  • =<*
  • ==6.17
  • <3042add80c2c50bd127d570b83319af612efde65
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
batman-adv: dat: handle forward allocation error

In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: handle forward allocation error batadv_dat_forward_data() calls pskb_copy_for_clone() to duplicate an skb for each DHT candidate, but does not check the return value before passing it to batadv_send_skb_prepare_unicast_4addr(). That function dereferences the skb unconditionally, so a failed allocation triggers a NULL pointer dereference. Skip forwarding to the current DHT candidate on allocation failure.

Affected products

Linux
  • <2d8826a2d3657cea66fb0370f9e521575a673871
  • =<5.15.*
  • <9cceea8eeba710def2a5707ee00f00c74a9a1cac
  • =<6.18.*
  • =<6.12.*
  • <2edb8aeb3cdda9d00ec4997252dc5bcd6f54d8ef
  • <9bcebaedfb8479cb4affb23c7a0d000ca9a20e73
  • ==3.8
  • =<7.0.*
  • <cf48e75fc4fe0d5cc7721c82d454221d01367b93
  • <866ac1d57040ed0b44ca732e3c66b3aa6b93011c
  • <ce0c381199402a2c58f4599f4f6ed100d872d0da
  • =<*
  • =<6.6.*
  • <3.8
  • =<6.1.*
  • =<5.10.*
  • <4d420d9ee70a220a2cd95aa0dd2e15acad66a505
Dismissed
(max. allowed matches exceeded)
created 3 weeks ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: usb-audio: Bound MIDI endpoint descriptor scans

In the Linux kernel, the following vulnerability has been resolved: ALSA: usb-audio: Bound MIDI endpoint descriptor scans snd_usbmidi_get_ms_info() validates the internal MIDIStreaming endpoint descriptor size before using baAssocJackID[], but the descriptor walker can still return a class-specific endpoint descriptor whose bLength exceeds the remaining bytes in the endpoint-extra scan. That leaves later flexible-array reads bounded by bLength, but not by the remaining bytes in the endpoint-extra scan. Stop walking when bLength is zero or extends past the remaining endpoint-extra scan.

Affected products

Linux
  • =<6.18.*
  • ==0868bc5654c07628c421547f0821650a8c2cb8f3
  • <4.5
  • ==5.7
  • =<7.0.*
  • ==78483c1c7741ffa72991d93d19a75bfdcc2cbf57
  • ==65d95462001c6ccd9bc9499c1fc9a90eca9de496
  • <5.7
  • =<6.1.*
  • <09141583bd97f4bbd7358e29fd138fe798467cdb
  • <4.20
  • <e2f1260a056eb3215c13c48c5378f3e4112dc3af
  • <d6854daa67be623860f4e1873fd3d3c275aba4ed
  • <4.15
  • <5.5
  • <3d3b2b01a3e73828e201ece96f863e7a3e0cdc6e
  • <4.10
  • <c65b137d351e21cbc5630e73ef0eb1e1d75f5b20
  • <728ab0c72e49ca27185067984cd565425eb69b2e
  • ==9e0c71f2f633b0442661966228827d1a33df485f
  • <c59159ce10e75b568cd0d4b29efcb0fb0ddecc94
  • =<5.15.*
  • =<*
  • ==ca767cf0152d18fc299cde85b18d1f46ac21e1ba
  • =<5.10.*
  • =<6.12.*
  • <a0226560540c16717efcceaf15c862cf115b01d3
  • =<6.6.*