huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2023-53577: kernel: bpf, cpumap: Make sure kthread is running before map update returns
Component: kernel
Severity: Low
CWE: CWE-367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A race condition was found in the Linux kernel's BPF cpumap implementation in the kthread lifecycle management. 
A local user can trigger this issue by running XDP redirect operations when the per-CPU kthread is stopped prematurely before processing queued frames, causing the cleanup code to find a non-empty ptr_ring and report warnings. This results in kernel warnings and denial of service through system instability.

Statement: The cpumap uses per-CPU kthreads to process XDP redirected packets. When a CPU map entry is being removed, kthread_stop is called which can return -EINTR if the thread hasn't fully started yet. Meanwhile, XDP programs may have already queued frames into the ptr_ring. The __cpu_map_ring_cleanup function expects the ring to be empty when called, but with the prematurely stopped kthread, queued frames remain unprocessed. This creates a state where frames were correctly handled by the XDP program but never consumed by the kthread, leading to warnings about non-empty rings. The fix ensures the kthread is fully running before allowing map updates to complete, preventing the race.

Affected upstream versions: 4.15
Fixed upstream versions: 0, 5.15.126, 6.1.45, 6.4.10, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b44d28b98f185d2f2348aa3c3636838c316f889e
CVE-2023-53578: kernel: net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()
Component: kernel
Severity: Low
CWE: CWE-131 (Incorrect Calculation of Buffer Size)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

An uninitialized memory access flaw was found in the Linux kernel's QRTR (Qualcomm IPC Router) protocol in the transmit resume handling. When processing RESUME_TX messages, if the packet size is smaller than the expected control structure, the qrtr_tx_resume function reads uninitialized memory from the skb buffer. This can lead to unpredictable behavior, kernel warnings from KMSAN (Kernel Memory Sanitizer), and potential crashes, causing denial of service.

Statement: QRTR is a message-based IPC mechanism used in Qualcomm SoCs to communicate between processors and subsystems. The protocol uses control messages for flow control, including QRTR_TYPE_RESUME_TX packets that signal readiness to receive more data. The qrtr_tx_resume function expects these packets to contain at least a full qrtr_ctrl_pkt structure and reads fields from that structure. Meanwhile, qrtr_endpoint_post allocates an skb of size 'size' (from the received message) and sets skb->len to match. When a malformed or crafted message arrives with type QRTR_TYPE_RESUME_TX but size less than sizeof(struct qrtr_ctrl_pkt), the allocated skb doesn't contain enough initialized data. When qrtr_tx_resume tries to access fields of the control packet, it reads beyond the initialized portion into whatever random data happened to be in that memory.

Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.178, 5.15.108, 6.1.25, 6.2.12, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3814d211ff13ee35f2d9437439a6c7df58524137
CVE-2023-53580: kernel: USB: Gadget: core: Help prevent panic during UVC unconfigure
Component: kernel
Severity: Moderate
CWE: CWE-764 (Multiple Locks of a Critical Resource)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A deadlock flaw was found in the Linux kernel's USB Gadget subsystem in the driver unbind path. 
A local privileged user can trigger this issue by removing a UVC gadget driver from a gadget configuration, causing the unbind callback to call usb_gadget_deactivate while the caller holds the connect_lock mutex. This results in a deadlock attempting to reacquire the same mutex, leading to a kernel panic or system hang.

Statement: The gadget_unbind_driver function calls the driver's unbind callback while holding the udc->connect_lock mutex. When the UVC gadget driver's unbind function calls usb_gadget_deactivate as part of its cleanup, that function attempts to acquire the same mutex, creating a classic self-deadlock. This issue was exposed by the interaction between kernel components and userspace in UVC gadget configurations. The fix is straightforward—drop the mutex before invoking the unbind callback, which matches the pattern used for bind callbacks.

Affected upstream versions: 6.1.35 < 6.1.46, 6.3.9 < 6.4, 6.4
Fixed upstream versions: 0, 6.1.46, 6.4, 6.4.11, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: bed19d95fcb9c98dfaa9585922b39a2dfba7898d
CVE-2023-53581: kernel: net/mlx5e: Check for NOT_READY flag state after locking
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-10-04T00:00:00+00:00

A race condition was found in the Linux kernel Mellanox mlx5 network driver's  traffic control offload flow management. 
A local user with privileges to configure traffic control flower filters can trigger concurrent flow deletion operations where the NOT_READY flag is checked before acquiring the necessary lock, allowing a workqueue task to concurrently remove the flow from the unready_flows list, which causes double-removal from the linked list and results in list corruption leading to denial of service via kernel crash or potentially memory corruption.

Statement: The issue arises because of incorrect lock ordering in the flow deletion path. When mlx5e_tc_del_fdb_flow() processes a flow deletion, it first checks the NOT_READY flag to determine if the flow is on the unready_flows list, then acquires the uplink_priv->unready_flows_lock mutex to remove it. However, between the flag check and lock acquisition, a workqueue task can acquire the same lock and remove the flow from the list. When the original thread then acquires the lock and attempts list removal, it performs a double-removal on an entry that is no longer in the list. This corrupts the linked list pointers, causing subsequent list operations to access freed memory containing poison values (0xdead000000000100). The race window is narrow, requiring the workqueue to execute between the flag check and lock acquisition. While this reliably causes kernel crashes when the race occurs, the underlying list corruption represents a memory safety violation that could potentially be leveraged for more sophisticated attacks with careful timing and heap manipulation.

Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.188, 5.15.121, 6.1.40, 6.4.5, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 30c281a77fb1b2d362030ea243dd663201d62a21
CVE-2023-53585: kernel: bpf: reject unhashed sockets in bpf_sk_assign
Component: kernel
Severity: Low
CWE: CWE-911 (Improper Update of Reference Count)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A reference counting flaw was found in the Linux kernel's BPF socket assignment helper when handling unhashed UDP sockets. When a BPF program assigns an unhashed UDP socket to a packet, the function increments the socket reference count assuming SOCK_RCU_FREE isn't set. However, subsequent bind or connect operations set this flag, causing the packet receive path to skip the reference decrement. This creates a permanent reference leak that prevents socket cleanup, leading to resource exhaustion and denial of service.

Statement: The bpf_sk_assign helper allows BPF programs to redirect packets to specific sockets, a powerful feature for custom load balancing or packet steering. The helper was designed around an assumption: SOCK_RCU_FREE (which controls whether sockets can be freed after an RCU grace period without explicit reference counting) remains stable throughout the packet's lifetime. For most sockets this is true—the flag is set at socket creation. UDP sockets are different: they're created without SOCK_RCU_FREE, and this flag is only added later when they're bound to a port via udp_lib_get_port. Originally, BPF couldn't access unhashed (unbound) UDP sockets, so this wasn't an issue. That changed when sockmap restrictions were lifted. Now the following sequence creates a leak: put an unbound UDP socket in a sockmap, pull it out and bpf_sk_assign it (incrementing refcount because SOCK_RCU_FREE isn't set), bind the socket (setting SOCK_RCU_FREE), then when the packet reaches tcp_v4_rcv, skb_steal_sock sees SOCK_RCU_FREE and skips the sock_put. The fix rejects unhashed sockets in bpf_sk_assign.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.195, 5.15.132, 6.1.53, 6.4.16, 6.5.3, 6.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 791a12102e5191dcb6ce0b3a99d71b5a2802d12a
CVE-2023-53586: kernel: scsi: target: Fix multiple LUN_RESET handling
Component: kernel
Severity: Moderate
CWE: CWE-821 (Incorrect Synchronization)
CVSS v3: 5.1 (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A race condition flaw was found in the Linux kernel SCSI target subsystem's LUN_RESET handling. When multiple remote initiator sessions send concurrent LUN_RESET commands, one session's reset can incorrectly drain commands from another session, causing the second session to receive a successful reset response even though its commands weren't cleaned up, which results in the initiator reissuing commands while the old ones are still executing and leads to command confusion and potential data integrity issues.

Statement: The issue arises because LUN_RESET operations from different sessions aren't properly serialized. When session1's LUN_RESET begins processing, it moves all running commands (from both sessions) to its local drain_task_list. Meanwhile, session2's LUN_RESET doesn't see session1's reset operation (because it removed itself from the TMR list) and doesn't see any commands (because session1 moved them). Session2 then incorrectly reports success to its initiator. The initiator believes its commands are aborted and reissues them, but the backend eventually completes the original commands, returning aborted task statuses. The initiator then encounters invalid ITT errors or accidentally looks up reused ITTs. This can cause I/O errors and potential data corruption if reissued commands overlap with still-executing original commands. The race requires precise timing between multiple sessions sending LUN_RESET commands concurrently.

Affected upstream versions: 4.11
Fixed upstream versions: 0, 5.10.180, 5.15.111, 6.1.28, 6.2.15, 6.3.2, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e1f59cd18a10969d08a082264b557876ca38766e
CVE-2023-53594: kernel: driver core: fix resource leak in device_add()
Component: kernel
Severity: Low
CWE: CWE-771 (Missing Reference to Active Allocated Resource)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A reference leak was found in the Linux kernel's driver core device registration logic. When kobject_add fails partway through device_add, the error cleanup attempts to free resources but fails because kobject_add has already cleared the device's parent pointer. This prevents cleanup_glue_dir from finding and releasing the glue directory's reference, causing permanent resource leaks that accumulate with repeated failures and eventually lead to denial of service.

Statement: The device_add function is the core device registration mechanism in Linux. It creates various sysfs structures, including "glue directories" that organize devices within the sysfs hierarchy. The flow looks like this: get_device_parent creates or finds a glue directory (incrementing its reference), sets dev->kobj.parent to point to it, then calls kobject_add to register the device kobject in sysfs. If kobject_add succeeds, everything's fine. But if it fails, it has a side effect: it sets dev->kobj.parent to NULL. The error cleanup then calls get_glue_dir to retrieve the glue directory so it can decrement the reference via cleanup_glue_dir. However, with dev->kobj.parent now NULL, get_glue_dir can't find the glue directory and returns NULL itself. cleanup_glue_dir checks for NULL and does nothing. The glue directory reference acquired earlier is never released.

Affected upstream versions: 3.10.105 < 3.11, 3.12.70 < 3.13, 4.4.40 < 4.5, 4.8.16 < 4.9, 4.9
Fixed upstream versions: 0, 3.11, 3.13, 4.5, 4.9, 5.15.99, 6.1.16, 6.2.3, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8d389e363075c2e1deb84a560686ea92123e4b8b
CVE-2023-53596: kernel: drivers: base: Free devm resources when unregistering a device
Component: kernel
Severity: Low
CWE: CWE-771 (Missing Reference to Active Allocated Resource)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A resource management issue was found in the Linux kernel's driver core regarding device-managed (devm) resource cleanup. When devices without buses or drivers are unregistered, their managed resources aren't properly freed because devres_release_all is only called for devices that have been probed. This causes resource leaks—particularly problematic when managed resources hold references to the device itself—preventing device objects from ever being freed and leading to denial of service through resource exhaustion.

Statement: The device-managed resource API (devm) allows drivers to tie resource allocations to device lifetimes. Historically, devres_release_all was called only during driver unbinding (in the driver probe failure or remove paths). This worked fine for traditional bus-based, driver-bound devices. However, some subsystems—particularly DRM/graphics—use device objects without traditional bus/driver bindings. For these devices, if a devm resource holds a reference to the device, you get a circular dependency: the device can't be released until resources are freed, but resources won't be freed until the device is released. This actually triggered a previous fix attempt (commit 2f8d16a996da) that was later reverted (commit a525a3ddeaca) due to double-free issues. The current fix calls devres_release_all in both device_del (during unregistration) and device_release (during final teardown), breaking the circular dependency while avoiding the earlier problems.

Affected upstream versions: 3.7
Fixed upstream versions: 0, 5.10.258, 5.15.209, 6.1.53, 6.4.16, 6.5.3, 6.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 83e2ec36a92432e9445e853c12becbbae353b511
CVE-2023-53597: kernel: cifs: fix mid leak during reconnection after timeout threshold
Component: kernel
Severity: Moderate
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

cifs: fix mid leak during reconnection after timeout threshold

When the number of responses with status of STATUS_IO_TIMEOUT
exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect
the connection. But we do not return the mid, or the credits
returned for the mid, or reduce the number of in-flight requests.

This bug could result in the server->in_flight count to go bad,
and also cause a leak in the mids.

This change moves the check to a few lines below where the
response is decrypted, even of the response is read from the
transform header. This way, the code for returning the mids
can be reused.

Also, the cifs_reconnect was reconnecting just the transport
connection before. In case of multi-channel, this may not be
what we want to do after several timeouts. Changed that to
reconnect the session and the tree too.

Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name
MAX_STATUS_IO_TIMEOUT.


Affected upstream versions: 5.9.5 < 5.10, 5.10
Fixed upstream versions: 0, 5.10, 5.15.150, 6.1.42, 6.4.7, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: df31d05f0678cdd0796ea19983a2b93edca18bb0
CVE-2023-53598: kernel: bus: mhi: host: Range check CHDBOFF and ERDBOFF
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A missing bounds check flaw was found in the Linux kernel's Modem Host Interface bus driver in the channel doorbell offset validation logic. 
A local user can trigger this issue on systems with MHI devices (typically Qualcomm modems or wireless cards) by using a device that provides malformed or malicious channel configuration data during initialization, causing an out-of-bounds array access. This leads to kernel memory corruption resulting in a panic or denial of service.

Statement: MHI devices communicate channel configuration through doorbell offset values (CHDBOFF and ERDBOFF) that index into the device's register space. The driver reads these offsets from device memory during initialization but historically failed to validate that they fall within legitimate bounds. A malicious device—or a legitimate device with corrupted firmware—can supply offset values that point outside the allocated channel context array. When the driver attempts to use these offsets, it accesses arbitrary kernel memory, typically triggering an immediate panic. Physical access is generally required to connect a malicious device, though in some cases (like M.2 modems) a compromised device firmware could supply bad values.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.192, 5.15.112, 6.1.28, 6.2.15, 6.3.2, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 372f1752b74572b0a9d2288841eab7db17daccae
CVE-2023-53602: kernel: wifi: ath11k: fix memory leak in WMI firmware stats
Component: kernel
Severity: Low
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix memory leak in WMI firmware stats

Memory allocated for firmware pdev, vdev and beacon statistics
are not released during rmmod.

Fix it by calling ath11k_fw_stats_free() function before hardware
unregister.

While at it, avoid calling ath11k_fw_stats_free() while processing
the firmware stats received in the WMI event because the local list
is getting spliced and reinitialised and hence there are no elements
in the list after splicing.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1


Affected upstream versions: 5.6
Fixed upstream versions: 0, 6.1.42, 6.4.7, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 86f9330a49d1464849482298dd34d361859183eb
CVE-2023-53605: kernel: drm: amd: display: Fix memory leakage
Component: kernel
Severity: Low
CWE: CWE-771 (Missing Reference to Active Allocated Resource)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A memory leak flaw was found in the Linux kernel's AMD display driver in the display context construction logic. A local user can trigger this issue during AMD GPU initialization when the dc_construct_ctx function fails to release allocated memory in error paths. This results in permanent memory leaks leading to resource exhaustion and denial of service.

Statement: The dc_construct_ctx function is responsible for initializing the display controller context during AMD GPU driver initialization. When errors occur during this process, certain code paths fail to free previously allocated memory structures before returning. Since this function is called during driver initialization and errors are typically fatal (preventing the driver from loading successfully), the leaked memory persists until system reboot. While the leak occurs once per failed initialization rather than repeatedly during runtime, it represents wasted memory resources that cannot be reclaimed without rebooting.

Affected upstream versions: 4.15
Fixed upstream versions: 0, 5.10.173, 5.15.99, 6.1.16, 6.2.3, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d473c55ce1975c9e601c25293328a5039225d2b2
CVE-2023-53606: kernel: nfsd: clean up potential nfsd_file refcount leaks in COPY codepath
Component: kernel
Severity: Low
CWE: CWE-911 (Improper Update of Reference Count)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A reference leak flaw was found in the Linux kernel's NFS server implementation in the file copy operation handling. 
A local user can trigger this issue when asynchronous copy operations fail to create worker threads, causing nfsd_file references held by the embedded copy structure to leak. This results in permanent reference leaks preventing proper file cleanup and leading to resource exhaustion and denial of service.

Statement: The NFSD COPY operation supports both synchronous and asynchronous modes. For synchronous copies, an nfsd4_copy structure is embedded in the compound and holds nfsd_file references for the duration of the operation. For asynchronous copies, a separate dynamically allocated structure is created with its own references. The cleanup logic is asymmetric—the async copy structure releases its references in nfsd4_do_async_copy, but this function also releases the references from the embedded structure, even though that structure outlives the async operation. Additionally, if kthread_create fails for async copies, neither set of references is properly released, creating a permanent leak. The fix ensures embedded structure references are always cleaned up before the function returns and consolidates cleanup logic.

Affected upstream versions: 4.20
Fixed upstream versions: 0, 5.10.220, 5.15.154, 6.1.16, 6.2.3, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: fd63299db8090307eae66f2aef17c8f00aafa0a9