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, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
device property: initialize the remaining fields of fwnode_handle in fwnode_init()

In the Linux kernel, the following vulnerability has been resolved: device property: initialize the remaining fields of fwnode_handle in fwnode_init() If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnode_init(), its secondary pointer will contain uninitialized memory which likely will be neither NULL nor IS_ERR() and so may end up being dereferenced (for example: in dev_to_swnode()). Set fwnode->secondary to NULL on initialization. While at it: initialize the remaining fields of struct fwnode_handle too just to be sure. [ Fix typo in commit message. - Danilo ]

Affected products

Linux
  • <f0b4e1cc8ad76baf49d898727eb52e91a4ef0544
  • <c81e2af41de6a159837c7129a4fc444ac6e48046
  • <5.11
  • =<6.6.*
  • =<*
  • ==5.11
  • <173b61c9276c7b3a5fbcc63ae7aafc897fee1e18
  • <0198d579948322cda5178b9672d448375a32f947
  • <9c86a1f930bb2ddb85f867b4736716e82a4a4683
  • =<6.12.*
  • =<6.18.*
  • =<7.1.*
  • =<5.15.*
  • <c8542b68ba6ef4f61072098893a3f5b71c569b6c
  • <7eba000621fff223dd7bab484d48918c7c77a307
  • =<6.1.*
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ALSA: ump: fix double free of out_cvts on rawmidi error

In the Linux kernel, the following vulnerability has been resolved: ALSA: ump: fix double free of out_cvts on rawmidi error snd_ump_attach_legacy_rawmidi() allocates the legacy conversion array ump->out_cvts and, on the snd_rawmidi_new() error path, frees it with kfree() but leaves ump->out_cvts pointing at the freed memory. When the endpoint is later torn down, snd_ump_endpoint_free() frees ump->out_cvts a second time, resulting in a double free. The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes snd_rawmidi_new() fail reaches this path on enumeration. Clear ump->out_cvts after freeing it on the error path so it is not freed again during teardown. Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

Affected products

Linux
  • ==6.5
  • <70c977815af0d997feb2d0c5d284d55689bf7051
  • <6.5
  • =<6.6.*
  • =<*
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <3302aaeac4f7ee6b775850db21d5f61064ce70ad
  • <e84d2e53a05c78a04d1343eeb0f31a79456e79fc
  • <032746c2dd9a4ea0774b04ac8a29e2ea628f106e
  • <c57001f55f97ef856fb6527e376c5c4a056a53a4
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ASoC: topology: Check PCM and DAI name strings before use

In the Linux kernel, the following vulnerability has been resolved: ASoC: topology: Check PCM and DAI name strings before use Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints. A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field. Reject unterminated PCM and DAI name fields before consuming them as C strings.

Affected products

Linux
  • <4.6
  • =<*
  • <ba37b62ed0a443b8e23f53a7477e7f2537fd34c7
  • =<7.1.*
  • <b7e44d1986d6671342c19b82192189ca5db5dab7
  • ==4.6
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
dm-log: fix a bitset_size overflow on 32bit machines

In the Linux kernel, the following vulnerability has been resolved: dm-log: fix a bitset_size overflow on 32bit machines Commit c20e36b7631d ("dm log: fix out-of-bounds write due to region_count overflow") made sure that region_count could fit in an unsigned int. But the bitmap memory isn't allocated based on region_count. It uses bitset_size (a size_t variable). The first step of calculating bitset_size is to set it to region_count, rounded up to a multiple of BITS_PER_LONG. If region_size is less than BITS_PER_LONG smaller than UINT_MAX, it will get rounded up to 2^32. On a 32bit architecture, this will make bitset_size wrap around to 0 and fail, despite region_count being valid. Since bitset_size gets divided by 8, it can hold any valid region_count. It just needs a special case to handle the rollover. If it is 0, the value rolled over, and bitset size should be set to the number of bytes needed to hold 2^32 bits.

Affected products

Linux
  • =<6.6.*
  • <7.1
  • =<*
  • <cdc4ddf9db2cb79f4ab86b1a509b7ac21b0b6cf5
  • =<7.1.*
  • <6.1.178
  • <e0b0163a65758ec3a2361ae1cea407898c27f21e
  • =<5.10.*
  • <d05e0edfecf5260e6dddd28b2f0cce02bfc6ed7a
  • =<6.18.*
  • ==7.1
  • <6.6.145
  • =<6.1.*
  • <7.1
  • <79feb87ab2396d49b9b65e4bb815d33cc71cba47
  • <9743132a41f4d9d0e54c5f2adcb821b04796bab1
  • <6.12.97
  • =<6.12.*
  • <1c3412b584e1fb6c665ff33ba7259253bc0082cb
  • =<5.15.*
  • <5.10.261
  • <4b0de5a3ac1fd42acb0dc1f80ac5747e3287d723
  • <6.18.40
  • <567602fa72d57169365cbc589e0b8c3be900636d
  • ==4ec8323b9f0764a14d532b1ae9b87f8a9fecb867
  • <5.15.212
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
HID: bpf: Fix hid_bpf_get_data() range check

In the Linux kernel, the following vulnerability has been resolved: HID: bpf: Fix hid_bpf_get_data() range check hid_bpf_get_data() returns a pointer into the HID-BPF context data when the caller-provided offset and size fit inside ctx->allocated_size. The current check adds rdwr_buf_size and offset before comparing the result against ctx->allocated_size. Since both values are unsigned, a very large size can wrap the sum below ctx->allocated_size and make the helper return a pointer even though the requested range is not contained in the backing buffer. Use check_add_overflow() to reject wrapped range ends before comparing the requested range end against ctx->allocated_size.

Affected products

Linux
  • <f81bc5a709dcbaf2a3bbef4ca7167f93900cc39f
  • <2d044049421dd48212b28646a850749d4a2d57fa
  • =<*
  • <61a959b82f1aecd6d2d35c208013dd077cac9d10
  • =<6.18.*
  • =<6.12.*
  • <6.3
  • ==6.3
  • =<7.1.*
  • <ca373549140dfb386aa2de38364b58441b1f4885
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
nvdimm/btt: Handle preemption in BTT lane acquisition

In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: Handle preemption in BTT lane acquisition BTT lanes serialize access to per-lane metadata and workspace state during BTT I/O. The btt-check unit test reports data mismatches during BTT writes due to a race in lane acquisition that can lead to silent data corruption. The existing lane model uses a spinlock together with a per-CPU recursion count. That recursion model stopped being valid after BTT lanes became preemptible: another task can run on the same CPU, observe a non-zero recursion count, bypass locking, and use the same lane concurrently. BTT lanes are also held across arena_write_bytes() calls. That path reaches nsio_rw_bytes(), which flushes writes with nvdimm_flush(). Some provider flush callbacks can sleep, making a spinlock the wrong primitive for the lane lifetime. Replace the spinlock-based recursion model with a dynamically allocated per-lane mutex array and take the lane lock unconditionally. Add might_sleep() to catch any future atomic-context caller. Found with the ndctl unit test btt-check.sh.

Affected products

Linux
  • ==40ba3fa21250e361bdd8f00800b3e2cb6160de95
  • <4.20
  • =<6.6.*
  • =<*
  • =<7.1.*
  • <6.1.178
  • <6.6
  • <6.7
  • <73e35c1bdfa160b41fdbe204e02325f0687de506
  • =<6.18.*
  • <fd7a97b2514cfc4b4cc067a27dd39bde2a8b1735
  • <6.6.145
  • <8d4b989d9c9afe5f185aa5853b666fc4617afe9e
  • =<6.1.*
  • <5.11
  • ==6.7
  • ==2577fece583c7c05cda7ad50dde7638c962665e1
  • ==66eb7b7f23dd9aec5356e7054dd3596ae7648ff5
  • <5.16
  • =<6.12.*
  • <417918783bcfe0be135019df16a267b3af442efd
  • ==b0e7a935739f33ed2bd6868b89f97dd4c2683c26
  • <4eafa810b042d985ec6bbf5b514414e73cee6f6f
  • <5.5
  • <5c53406098b599c420b031e6ec5ba8a2f3794c50
  • ==b27751fb1f271bbb78d5993c0b10011628e40e18
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT

In the Linux kernel, the following vulnerability has been resolved: ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not belong to the same superblock as the original file. Currently, this validation is performed inside ext4_move_extents() by mext_check_validity(), but only after lock_two_nondirectories() has already acquired the inode locks. When the donor fd refers to a file on a different filesystem (e.g., overlayfs), this late validation creates a circular lock dependency: CPU0 (overlayfs write) CPU1 (ext4 ioctl) ---- ---- inode_lock(ovl_inode) mnt_want_write_file(filp) sb_start_write(ext4_sb) [sb_writers] backing_file_write_iter() vfs_iter_write(real_file) file_start_write(real_file) sb_start_write(ext4_sb) [blocked by freeze] lock_two_nondirectories() inode_lock(ovl_inode) [blocked] With a concurrent freeze operation holding sb_writers write side, this forms a deadlock cycle: CPU0 waits for freeze to complete, freeze waits for CPU1's sb_writers reader to exit, CPU1 waits for CPU0's inode lock. Since EXT4_IOC_MOVE_EXT exchanges physical extents between two files, it fundamentally requires both files to reside on the same ext4 filesystem. Moving the superblock check before any lock acquisition is both semantically correct and eliminates the circular dependency by ensuring that cross-filesystem donor fds are rejected before sb_writers or inode locks are taken.

Affected products

Linux
  • ==3.18
  • <fb52013cad9e9b7d3a6a14ea1bcd841e41da7c6c
  • =<*
  • <c143957520c6c9b5cd72e0de8b52b814f0c576fe
  • <3.18
  • =<6.12.*
  • =<7.1.*
  • <74796e886ca39fcb0d3fd36ea6a39c62784ab6fb
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
cxl/region: Fill first free targets[] slot during auto-discovery

In the Linux kernel, the following vulnerability has been resolved: cxl/region: Fill first free targets[] slot during auto-discovery Any invalid endpoint decoder pointer in the target array of an active region is not allowed by cxl driver. This means cxl driver always assumes the first p->nr_targets entries of the target array in an auto-assembly region are valid. However, there are scenarios that could leave NULL endpoint decoder pointer holes in the target array. 1. When cxl_cancel_auto_attach() removes an endpoint decoder from a target array, the target slot is set to NULL. If the removed endpoint decoder is not the last element in the target array, the target array will contain a NULL hole. 2. When a auto-assembly region removes an assigned endpoint decoder, if the removed endpoint decoder is not the last element in the target array, always remains a NULL hole in the target array. When a NULL pointer hole exists in a region's target array, it introduces two potential problems: 1. Access an endpoint decoder via a NULL pointer. it always trigger calltrace like that. Oops: general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KASAN PTI RIP: 0010:cxl_calc_interleave_pos+0x26/0x810 [cxl_core] Call Trace: <TASK> cxl_region_attach+0xc50/0x2140 [cxl_core] cxl_add_to_region+0x321/0x2330 [cxl_core] discover_region+0x92/0x150 [cxl_port] device_for_each_child+0xf3/0x170 cxl_port_probe+0x150/0x200 [cxl_port] cxl_bus_probe+0x4f/0xa0 [cxl_core] really_probe+0x1c8/0x960 __driver_probe_device+0x323/0x450 driver_probe_device+0x45/0x120 __device_attach_driver+0x15d/0x280 bus_for_each_drv+0x10f/0x190 2. Not having enough valid endpoint decoders attached to an auto-assembly region. if an auto-assembly region is created with lock flag or assigned endpoint decoder with lock flag, which means assigned endpoint decoder will not be reset during detaching, they could re-attach to the auto-assembly region again. But cxl region driver relies on p->nr_targets to verify whether the required number of endpoint decoders has been attached, and NULL endpoint decoder pointers are still counted in that case. To fix above issues, adjust cxl_region_attach_auto() logic to find the first free target slot for endpoint decoder attachment, this ensures NULL holes in the target array are filled, rather than adding new endpoint decoders at the tail of the target array.

Affected products

Linux
  • <6fde3fcdfec438ba0df26e25a8ac7c3707211799
  • =<*
  • ==6.19
  • =<7.1.*
  • <6.19
  • <aa8a76711c15041ec1e42c3a74c15c2df0bd31f6
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
RDMA/siw: Fix endpoint/socket association handling

In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix endpoint/socket association handling Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within. This fixes a: BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075) which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.

Affected products

Linux
  • <5.3
  • <b28d513393f81e2de00f82970487a9d001557e4e
  • =<*
  • =<6.18.*
  • =<6.12.*
  • =<7.1.*
  • <f6183983ce1ff254d629a333739082b39d7c5eb6
  • ==5.3
  • <b6cf763eee0a932792bef64ceaca568d324192fc
  • <ea4f6f6c53577fb3f05dbd78b15e586772d49831
Dismissed
(max. allowed matches exceeded)
created 3 weeks, 4 days ago Activity log
  • Created & dismissed (max. allowed matches exceeded) suggestion
wifi: ath11k: cancel SSR work items during PCI shutdown

In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: cancel SSR work items during PCI shutdown A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts. Simplified trace: dma_free_attrs mhi_deinit_dev_ctxt [mhi] ath11k_pci_power_down [ath11k_pci] ath11k_pci_shutdown [ath11k_pci] device_shutdown kernel_restart On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The power-down phase deinitializes MHI and frees DMA resources. Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR recovery flow. As a result, the shutdown path (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR recovery sequence. Fix this by canceling SSR-related work items during PCI shutdown, marking the device as unregistering, and serializing the RDDM callback path that checks and queues reset_work. This ensures that no new SSR recovery work can be queued once teardown has started, and that any in-flight recovery work is fully synchronized before device power-down, preventing MHI teardown and DMA resource freeing from running more than once. Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k devices do not queue reset_work in normal SSR flows. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Affected products

Linux
  • <8c79aac429b583301f387374ff37c59be671df87
  • =<*
  • ==5.19
  • =<7.1.*
  • <5.19
  • <53dd29e8aeb2a1b5f079178551836b85fc6b53df