Nixpkgs security tracker

Login with GitHub

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 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr()

In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_tx_check_aggr() Move the NULL check for 'sta' before dereferencing it to prevent a possible crash.

Affected products

Linux
  • =<6.18.*
  • <6.11
  • <28ed0b61f67386c0ba1213227d350005000240fd
  • =<7.0.*
  • =<*
  • <83ae3a18ba957257b4c406273d2da2caeea2b439
  • ==6.11
  • =<6.12.*
  • <b0332428a8d4cf93752eda9e2b0d5585525e689f
  • <93d0694fb56de4628a921244d7f100c28acd2def
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
idpf: fix double free and use-after-free in aux device error paths

In the Linux kernel, the following vulnerability has been resolved: idpf: fix double free and use-after-free in aux device error paths When auxiliary_device_add() fails in idpf_plug_vport_aux_dev() or idpf_plug_core_aux_dev(), the err_aux_dev_add label calls auxiliary_device_uninit() and falls through to err_aux_dev_init. The uninit call will trigger put_device(), which invokes the release callback (idpf_vport_adev_release / idpf_core_adev_release) that frees iadev. The fall-through then reads adev->id from the freed iadev for ida_free() and double-frees iadev with kfree(). Free the IDA slot and clear the back-pointer before uninit, while adev is still valid, then return immediately. Commit 65637c3a1811 ("idpf: fix UAF in RDMA core aux dev deinitialization") fixed the same use-after-free in the matching unplug path in this file but missed both probe error paths.

Affected products

Linux
  • <f319de7074e1728a9f9ff7134257360c694ec2b2
  • =<6.18.*
  • <722b91d5086a249318c9d0e2b36aeac80ba8c808
  • =<7.0.*
  • =<*
  • <6c77b9510829a424d1b74409b7db9456e3522871
  • <6.17
  • ==6.17
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
iommu/riscv: Remove overflows on the invalidation path

In the Linux kernel, the following vulnerability has been resolved: iommu/riscv: Remove overflows on the invalidation path Since RISC-V supports a sign extended page table it should support a gather->end of ULONG_MAX, but if this happens it will infinite loop because of the overflow. Also avoid overflow computing the length by moving the +1 to the other side of the <

Affected products

Linux
  • =<6.18.*
  • <9f0632b0d4246675fa221aa1a3bffadf9c6bd9ac
  • =<7.0.*
  • =<*
  • ==6.13
  • <e4b7687784153481de45fd39fb97ba3919605c0c
  • <40a13b49957937427bc23e78eb50679df4396a47
  • <6.13
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs. The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash. [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation. (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)

Affected products

Linux
  • <30bb2ec6695d62f63db4aa6179c4626834ed0cd6
  • =<7.0.*
  • =<*
  • <183182235f6d53bac62c6c39014738a54a68dfa6
  • ==6.0
  • <6.0
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind

In the Linux kernel, the following vulnerability has been resolved: net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via pn_socket_autobind(): kernel BUG at net/phonet/socket.c:213! RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline] RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421 Call Trace: sock_sendmsg_nosec+0x112/0x150 net/socket.c:797 __sock_sendmsg net/socket.c:812 [inline] __sys_sendto+0x402/0x590 net/socket.c:2280 ... pn_socket_autobind() calls pn_socket_bind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero: err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn)); if (err != -EINVAL) return err; BUG_ON(!pn_port(pn_sk(sock->sk)->sobject)); return 0; /* socket was already bound */ However pn_socket_bind() also returns -EINVAL when sk->sk_state is not TCP_CLOSE, even when the socket has never been bound and pn_port() is still 0. In that case the BUG_ON() fires and panics the kernel from a user-triggerable path. Treat the "bind returned -EINVAL but pn_port() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno.

Affected products

Linux
  • =<7.0.*
  • <6db58ee730bf434d1afca91b91826e26688856ed
  • =<*
  • <2.6.28
  • <5b0c911bcdbd982f7748d11c0b39ec5808eae2de
  • ==2.6.28
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace(). Both functions check: if (!dc_dmub_srv || !dc_dmub_srv->dmub) and then call DC_LOG_ERROR() inside that block. DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash. Fix this by splitting the checks. First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid. Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166)

Affected products

Linux
  • <4ae3e16f4b3bf64140f773629b765d605ee079a9
  • =<7.0.*
  • =<*
  • <5.14
  • ==5.14
  • <b37a978e6d8c33fbfa4abc5dcca4c7cfc6d01f22
Dismissed
(exclusively hosted service)
Permalink CVE-2026-57920
7.7 HIGH
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Network (N)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): Low (L)
  • User Interaction (UI): None (N)
  • Scope (S): Changed (C)
  • Confidentiality (C): High (H)
  • Integrity (I): None (N)
  • Availability (A): None (N)
  • Modified Attack Vector (MAV): Network (N)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): Low (L)
  • Modified User Interaction (MUI): None (N)
  • Modified Confidentiality (MC): High (H)
  • Modified Scope (MS): Changed (C)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): None (N)
created 1 month ago Activity log
  • Created & dismissed (exclusively hosted service) suggestion
Peplink InControl 2 through 2.14.2 before 2026-06-03 allows use of …

Peplink InControl 2 through 2.14.2 before 2026-06-03 allows use of a semicolon to bypass access-control rules for certain /rest/o/{orgId} endpoints.

Affected products

InControl
  • <2026-06-03
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty()

In the Linux kernel, the following vulnerability has been resolved: nilfs2: reject zero bd_oblocknr in nilfs_ioctl_mark_blocks_dirty() nilfs_ioctl_mark_blocks_dirty() uses bd_oblocknr to detect dead blocks by comparing it with the current block number bd_blocknr. If they differ, the block is considered dead and skipped. However, bd_oblocknr should never be 0 since block 0 typically stores the primary superblock and is never a valid GC target block. A corrupted ioctl request with bd_oblocknr set to 0 causes the comparison to incorrectly match when the lookup returns -ENOENT and sets bd_blocknr to 0, bypassing the dead block check and calling nilfs_bmap_mark() on a non-existent block. This causes nilfs_btree_do_lookup() to return -ENOENT, triggering the WARN_ON(ret == -ENOENT). Fix this by rejecting ioctl requests with bd_oblocknr set to 0 at the beginning of each iteration. [ryusuke: slightly modified the commit message and comments for accuracy]

Affected products

Linux
  • =<6.18.*
  • =<5.10.*
  • =<7.0.*
  • <b88f905d4449b70da6bda547be546e365e44352e
  • =<6.6.*
  • =<*
  • <2.6.30
  • <9472d37799a0b9ff9b99639f35961ac2f0b3c9be
  • <65e07964b4b2daf9a54e686cf0fa72d74a9648a8
  • =<6.12.*
  • <e5ff0ba4b6983cdbcc826efc201e7179ece5d46f
  • <4525658002be3ad310b16bf8db48c8adb6a55d32
  • =<6.1.*
  • <94094e70fe292c9566502772d4d4d6d6a99204b1
  • <e0a0c4903cbba351f0f5b5d104960d3a5b23202f
  • ==2.6.30
  • =<5.15.*
  • <be3e5d10643d3be1cbac9d9939f220a99253f980
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
arm64: Reserve an extra page for early kernel mapping

In the Linux kernel, the following vulnerability has been resolved: arm64: Reserve an extra page for early kernel mapping The final part of [data, end) segment may overflow into the next page of init_pg_end[1] which is the gap page before early_init_stack[2]: [1] crash_arm64_v9.0.1> vtop ffffffed00601000 VIRTUAL PHYSICAL ffffffed00601000 83401000 PAGE DIRECTORY: ffffffecffd62000 PGD: ffffffecffd62da0 => 10000000833fb003 PMD: ffffff80033fb018 => 10000000833fe003 PTE: ffffff80033fe008 => 68000083401f03 PAGE: 83401000 PTE PHYSICAL FLAGS 68000083401f03 83401000 (VALID|SHARED|AF|NG|PXN|UXN) PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffffffec00d0040 83401000 0 0 1 4000 reserved [2] ffffffed002c8000 (r) __pi__data ffffffed0054e000 (d) __pi___bss_start ffffffed005f5000 (b) __pi_init_pg_dir ffffffed005fe000 (b) __pi_init_pg_end ffffffed005ff000 (B) early_init_stack ffffffed00608000 (b) __pi__end For 4K pages, the early kernel mapping may use 2MB block entries but the kernel segments are only 64KB aligned. Segment boundaries that fall within a 2MB block therefore require a PTE table so that different attributes can be applied on either side of the boundary. KERNEL_SEGMENT_COUNT still correctly counts the five permanent kernel VMAs registered by declare_kernel_vmas(). However, since commit 5973a62efa34 ("arm64: map [_text, _stext) virtual address range non-executable+read-only"), the early mapper also maps [_text, _stext) separately from [_stext, _etext). This adds one more early-only split and can require one more page-table page than the existing EARLY_SEGMENT_EXTRA_PAGES allowance reserves. Increase the 4K-page early mapping allowance by one page to cover that additional split. [catalin.marinas@arm.com: rewrote part of the commit log] [catalin.marinas@arm.com: expanded the code comment]

Affected products

Linux
  • =<6.18.*
  • ==6.18
  • <6.18
  • =<7.0.*
  • <6.18
  • =<*
  • <dcb89deed40ba55ff7020061712fdabf098cc2cc
  • <9fe9e3acaa14921b0cf0d6cc2de5b562499bf721
  • <a4ff33053da0a34b14abb5c96dc5a48379e26fce
  • =<6.12.*
  • <4d8e74ad4585672489da6145b3328d415f50db82
  • <6.12.91
  • ==88025faf2aa08c7468d68d8cb31a53b55aae6ee0
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
vfio/pci: Clean up DMABUFs before disabling function

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Clean up DMABUFs before disabling function On device shutdown, make vfio_pci_core_close_device() call vfio_pci_dma_buf_cleanup() before the function is disabled via vfio_pci_core_disable(). This ensures that all access via DMABUFs is revoked before the function's BARs become inaccessible. This fixes an issue where, if the function is disabled first, a tiny window exists in which the function's MSE is cleared and yet BARs could still be accessed via the DMABUF. The resources would also be freed and up for grabs by a different driver.

Affected products

Linux
  • ==6.19
  • =<7.0.*
  • =<*
  • <6.19
  • <d97708701434ce72968e771976aaf9d3438fcafd
  • <4f1000a30f67cf7d328059242776a858611d5ef9