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
Bluetooth: fix memory leak in error path of hci_alloc_dev()

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: fix memory leak in error path of hci_alloc_dev() Early failures in Bluetooth HCI UART configuration leak SRCU percpu memory. When device initialization fails before hci_register_dev() completes, the HCI_UNREGISTER flag is never set. As a result, when the device reference count reaches zero, bt_host_release() evaluates this flag as false and falls back to a direct kfree(hdev). Because hci_release_dev() is bypassed, the SRCU struct initialized early in hci_alloc_dev() is never cleaned up, resulting in a leak of percpu memory. Fix the leak by explicitly calling cleanup_srcu_struct() in the fallback (unregistered) branch of bt_host_release() before freeing the device.

Affected products

Linux
  • =<5.15.*
  • =<*
  • ==6.16
  • <6.6.143
  • <5.11
  • <5b7dfca6f852e6b9d809fd0263b5427cc9fb33fd
  • ==0e5c144c557df910ab64d9c25d06399a9a735e65
  • <6.16
  • <0622e527a31d4b44737fed5c1a2ac1fc2cfb5184
  • <bc2efe73c194a74839d7cf57b63880d97e21d309
  • =<6.1.*
  • =<6.18.*
  • <ce4b4cac3c5749b6aa75e62e2991ae2263f2f889
  • <f82799407a50af7bcacacf09cc9b279af8fe9b81
  • <6.16
  • =<6.12.*
  • <c016118b9e51eeaf5bc93850d4c455a3b583c0aa
  • <5.15.210
  • <6.1.176
  • <6.12.94
  • ==dd4becd3fd4102696e1c15e6d260a1712a2d8685
  • =<7.0.*
  • <37b3009bf5976e8ab77c8b9a9bc3bbd7ff49e37f
  • =<6.6.*
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ovl: keep err zero after successful ovl_cache_get()

In the Linux kernel, the following vulnerability has been resolved: ovl: keep err zero after successful ovl_cache_get() ovl_iterate_merged() stores PTR_ERR(cache) in err before checking IS_ERR(cache). On success err holds the truncated cache pointer and can be returned as a bogus non-zero error. The syzbot reproducer reaches this through overlay-on-overlay readdir: getdents64 iterate_dir(outer overlay file) ovl_iterate_merged() ovl_cache_get() ovl_dir_read_merged() ovl_dir_read() iterate_dir(inner overlay file) ovl_iterate_merged() Only compute PTR_ERR(cache) on the error path.

Affected products

Linux
  • =<*
  • =<7.0.*
  • <6.19
  • ==6.19
  • <e7051909a01bfb883bfa78b27514854068ac4b85
  • <1711b6ed6953cee5940ca4c3a6e77f1b3798cee2
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/core: Validate the passed in fops for ib_get_ucaps()

In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Validate the passed in fops for ib_get_ucaps() Sashiko pointed out it is not safe to rely only on the devt because char/block alias so if the user finds a block device with the same dev_t it can masquerade as a ucap cdev fd. Test the f_ops to only accept authentic cdevs.

Affected products

Linux
  • <6.15
  • =<*
  • <aa181287ebdcc53ee0ba5c2f8243e2d541ebc19b
  • ==6.15
  • =<6.18.*
  • =<7.0.*
  • <4a1b1ac2744694a2ecd66a84bdb1445f4ef24bee
  • <96b6e98ff12d50ed5817230c6f1188e1150d225d
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
udp: clear skb->dev before running a sockmap verdict

In the Linux kernel, the following vulnerability has been resolved: udp: clear skb->dev before running a sockmap verdict On the UDP receive path skb->dev is repurposed as dev_scratch (the truesize/state cache set by udp_set_dev_scratch()), through the union { struct net_device *dev; unsigned long dev_scratch; } in sk_buff. When a UDP socket is in a sockmap, sk_data_ready is sk_psock_verdict_data_ready(), which calls udp_read_skb() -> recv_actor() (sk_psock_verdict_recv) to run the attached SK_SKB verdict program in softirq. If that program calls a socket-lookup helper (bpf_sk_lookup_tcp/udp, bpf_skc_lookup_tcp), bpf_skc_lookup() does: if (skb->dev) caller_net = dev_net(skb->dev); skb->dev still holds the dev_scratch value (a non-NULL integer), so dev_net() dereferences it as a struct net_device * and the kernel takes a general protection fault on a non-canonical address in softirq: Oops: general protection fault, probably for non-canonical address 0x1010000800004a0 CPU: 1 UID: 0 PID: 1406 Comm: syz.2.19 Not tainted 7.1.0-rc6 #1 PREEMPT(full) RIP: 0010:bpf_skc_lookup net/core/filter.c:7033 [inline] RIP: 0010:bpf_sk_lookup+0x45/0x160 net/core/filter.c:7047 Call Trace: <IRQ> bpf_prog_4675cb904b7071f8+0x12e/0x14e bpf_prog_run_pin_on_cpu+0xc6/0x1f0 sk_psock_verdict_recv+0x1ba/0x350 udp_read_skb+0x31a/0x370 sk_psock_verdict_data_ready+0x2e3/0x600 __udp_enqueue_schedule_skb+0x4c8/0x650 udpv6_queue_rcv_one_skb+0x3ec/0x740 udp6_unicast_rcv_skb+0x11d/0x140 ip6_protocol_deliver_rcu+0x61e/0x950 ip6_input_finish+0xa9/0x150 NF_HOOK+0x286/0x2f0 ip6_input+0x117/0x220 NF_HOOK+0x286/0x2f0 __netif_receive_skb+0x85/0x200 process_backlog+0x374/0x9a0 __napi_poll+0x4f/0x1c0 net_rx_action+0x3b0/0x770 handle_softirqs+0x15a/0x460 do_softirq+0x57/0x80 </IRQ> The rmem charge that dev_scratch accounted for is released by skb_recv_udp() on dequeue, just above, so the scratch is dead by the time recv_actor() runs. Clear skb->dev so bpf_skc_lookup() falls back to sock_net(skb->sk), which skb_set_owner_sk_safe() set just above.

Affected products

Linux
  • <3c94f241f776562c489876ff506f366224565c21
  • <6.0
  • =<*
  • =<6.1.*
  • <90d35188aaa92b8f8b23f66335e0e91bf60103a3
  • <7d6d92d000ebe3a845a17c165c1d3a70c5d84fe1
  • ==6.0
  • =<6.6.*
  • =<6.18.*
  • <263779a6beff03b8b06f6d25566cb0f45af361f2
  • =<7.0.*
  • =<6.12.*
  • <6822eed69572000a181fa4e31fceacc60918c471
  • <1b585673a2249f13678e7ac443ac683ba767e0b6
Dismissed
(max. allowed matches exceeded)
Permalink CVE-2026-57452
5.5 MEDIUM
  • CVSS version (CVSS): 3.1
  • Attack Vector (AV): Local (L)
  • Attack Complexity (AC): Low (L)
  • Privileges Required (PR): None (N)
  • User Interaction (UI): Required (R)
  • Scope (S): Unchanged (U)
  • Confidentiality (C): None (N)
  • Integrity (I): None (N)
  • Availability (A): High (H)
  • Modified Attack Vector (MAV): Local (L)
  • Modified Attack Complexity (MAC): Low (L)
  • Modified Privileges Required (MPR): None (N)
  • Modified User Interaction (MUI): Required (R)
  • Modified Confidentiality (MC): None (N)
  • Modified Scope (MS): Unchanged (U)
  • Modified Integrity (MI): None (N)
  • Modified Availability (MA): High (H)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
Vim: Out-of-bounds Read with libsodium-encrypted Files

Vim is an open source, command line text editor. Prior to 9.2.0671, when Vim opens a file encrypted with the VimCrypt~04! or VimCrypt~05! method (xchacha20poly1305, requires the +sodium feature) whose body is shorter than a single libsodium secretstream header, an unsigned length calculation underflows and a subsequent decryption call reads far past the end of the input buffer, crashing Vim. This vulnerability is fixed in 9.2.0671.

Affected products

vim
  • ==< 9.2.0671
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers

In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix NULL-deref of opinfo->conn in oplock/lease break notifiers smb2_oplock_break_noti() and smb2_lease_break_noti() read opinfo->conn into a local with neither READ_ONCE() nor a NULL check. Both run from oplock_break() after opinfo_get_list() has dropped ci->m_lock, so a concurrent SMB2 LOGOFF (session_fd_check()) can set op->conn = NULL under ci->m_lock within that window. ksmbd_conn_r_count_inc(conn) then writes through NULL at offset 0xc4 -- a remotely triggerable oops. Guard both reads the way compare_guid_key() already does: read opinfo->conn with READ_ONCE() and return early if it is NULL, before allocating the work struct so nothing leaks. A NULL conn means the client is gone and the break is moot, so return 0; oplock_break() treats that as success and runs the normal teardown.

Affected products

Linux
  • =<*
  • <945a86b21b40fb17183f5b27461baa6f03e2467f
  • <e735dbd489e3ea02be78dba991056fe1138be51e
  • <b003086d76968298f22e7cf62239833b5a3a06b1
  • <6.6.143
  • <6.9
  • =<6.18.*
  • <1ff58dcfcab434ebb51649da33774fbb8e1f7b67
  • =<7.0.*
  • ==6.9
  • =<6.12.*
  • =<6.6.*
  • <75e33deda658c1ab3a9336cbdb1436536f9b3660
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
USB: serial: io_ti: fix heap overflow in get_manuf_info()

In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_ti: fix heap overflow in get_manuf_info() get_manuf_info() reads le16_to_cpu(rom_desc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmalloc_obj(), which is sizeof(struct edge_ti_manuf_descriptor) = 10 bytes. The Size field comes from the device and is only validated (in check_i2c_image()) to make sure the descriptor fits within TI_MAX_I2C_SIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver. valid_csum() is called after read_rom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access. Fix by rejecting descriptors with unexpected length before calling read_rom(). [ johan: amend commit message; also check for short descriptors ]

Affected products

Linux
  • <cfd634f6dfd40c49a84f9bddc2867a80e2e2623a
  • =<5.15.*
  • <b849f30d1a9e66aae6b715aaef66e427390cb081
  • <561edb021486e6723d841926aa4b48097da06190
  • =<*
  • =<6.1.*
  • =<6.18.*
  • <f96cf7bf9fbf15d7fcf0c91fec47ba8a010369ea
  • ==2.6.12
  • <d214d2341d4f9f447e36a7d012cdf6a6631a55f1
  • <d92f17af7097d10bdeddf26f66f34b354104b277
  • =<5.10.*
  • =<7.0.*
  • =<6.12.*
  • =<6.6.*
  • <2.6.12
  • <e168db91442b94e64fa82a7dd297983d48ea5cc0
  • <183c1076eca43bbb3e7bdf597456f91d81c73e74
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: mvpp2: limit XDP frame size to the RX buffer

In the Linux kernel, the following vulnerability has been resolved: net: mvpp2: limit XDP frame size to the RX buffer mvpp2 has short and long BM pools, and short pool buffers can be smaller than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with PAGE_SIZE as frame size. XDP helpers use frame_sz to validate tail growth and to derive the hard end of the data area. Advertising PAGE_SIZE for short buffers can let bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting memory or later tripping skb tailroom checks. Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches the actual buffer backing the packet.

Affected products

Linux
  • <3b8b0c3631b19faee53f0d15a49924129b063eec
  • =<5.15.*
  • =<*
  • <a3ee9231ccec6ec3be2de89c56f897055fd9eab1
  • <994bd2b58d2bd08aa97ec0836cc813cfcb00d749
  • <9545cc5ef18ca22d031f2f47c157192460652359
  • =<6.1.*
  • =<6.18.*
  • =<6.6.*
  • =<7.0.*
  • <910617a4e67dbdd5fdb39d9dc6a51e491e1b2c3e
  • <f3c6aa078927e6fe8121c9c591ddee8716c5305a
  • ==5.9
  • =<6.12.*
  • <ec8e1e5842bc0dbd4c272761f4db3651eecd0339
  • <5.9
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/umem: Fix truncation for block sizes >= 4G

In the Linux kernel, the following vulnerability has been resolved: RDMA/umem: Fix truncation for block sizes >= 4G When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries. When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation. Use the right types to hold DMA addresses.

Affected products

Linux
  • =<5.15.*
  • =<*
  • <baf8685bcf56dc1efb44b8f6a57c42516e549068
  • <afd35fec9297195b759078745549c2671223f24f
  • <cc644d5608e3b0dadc970bd6e6aa26b91ea07d0f
  • =<6.1.*
  • <8fe0231adebe086c8a459c790944ac026cd99c6e
  • =<6.18.*
  • ==5.2
  • <2ff4b7817e5b78070c30f5fb5e678e452a2628b3
  • =<7.0.*
  • <ac1aad8e1281534ce936c250f68084fc79c5469e
  • <dee2a49adeeb2a5e16a3fc858fa21b841c519802
  • =<6.12.*
  • <5.2
  • =<6.6.*
  • =<5.10.*
  • <15fe76e23615f502d051ef0768f86babaf08746c
Dismissed
(max. allowed matches exceeded)
created 1 month ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
net: guard timestamp cmsgs to real error queue skbs

In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.

Affected products

Linux
  • =<5.15.*
  • =<*
  • <e0665b2a8e90bb08bd205062c75662b502d31797
  • =<5.10.*
  • <71ff5cdd5da61d0438e902aa0fd68c28bc901abe
  • <4.11
  • <eb51a9ad3ceb01bc6c0fb608dbc856e03ee6f24a
  • <1ee90b77b727df903033db873c75caac5c27ec98
  • <3dde4fb941fa5649ab809f6cd3e20e0c424a4e31
  • =<6.1.*
  • =<6.18.*
  • ==cdaf15b43bd31003220cb080bcbbd57787a2fca9
  • <ad9a0374ee6d11048e1f74cd5180bad58b9848b4
  • =<6.12.*
  • <24a0d548d3a765cd4558224e4f8e06e14cba26e3
  • <4.11
  • =<7.0.*
  • ==4.11
  • <b903e9b5629ec8dd6db92174070045bf81ad7060
  • =<6.6.*