huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2023-53607: kernel: ALSA: ymfpci: Fix BUG_ON in probe function
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 assertion failure was found in the Linux kernel's Yamaha YMF sound card driver during buffer validation. The probe function includes a BUG_ON assertion that compares DMA buffer sizes without accounting for alignment, causing the assertion to fail when the aligned buffer size doesn't exactly match the requested size. This triggers a kernel warning and can lead to driver initialization failure and denial of service.

Statement: The YMF PCI sound driver allocates DMA buffers for audio operations during device probe. Recent changes to the DMA buffer allocation code made the bytes field reflect the aligned buffer size rather than the exact requested size—this ensures proper memory alignment for DMA operations. However, the snd_ymfpci_create function contains a snd_BUG_ON check that asserts the allocated size exactly matches the requested size. With the new alignment behavior, buffers are typically rounded up to page or cache-line boundaries, causing the sizes to differ slightly. When this happens, the assertion fires, producing kernel warnings and potentially failing driver initialization. While primarily a debug check rather than actual memory corruption, on systems with panic-on-warn enabled or depending on driver initialization behavior, this could prevent the sound card from functioning at all.

Affected upstream versions: 5.10.134 < 5.10.177, 4.9.325 < 4.10, 4.14.290 < 4.15, 4.19.254 < 4.20, 5.4.208 < 5.5, 5.11
Fixed upstream versions: 0, 4.10, 4.15, 4.20, 5.10.177, 5.15.106, 5.5, 6.1.23, 6.2.10, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 96e34c88000febc83e41aa7db0b0a41676314818
CVE-2023-53611: kernel: ipmi_si: fix a memleak in try_smi_init()
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 IPMI System Interface driver in the initialization error path. 
A local user can trigger this issue by loading the ipmi_si module when initialization fails after allocating the si_sm structure but before registering the shutdown handler. This causes the allocated memory to never be freed, resulting in a permanent memory leak leading to resource exhaustion and denial of service.

Statement: The try_smi_init function performs IPMI interface initialization and allocates the new_smi->si_sm structure early in the process. If an error occurs after this allocation but before the shutdown_smi handler is registered, the error cleanup path returns without freeing si_sm because shutdown_smi is the normal mechanism for releasing this resource. Since initialization failures don't retry, each failed attempt permanently leaks 1024 bytes. While individual leaks are relatively small, repeated module load attempts (such as through automatic hardware detection or manual troubleshooting) can accumulate significant memory loss.

Affected upstream versions: 4.18
Fixed upstream versions: 0, 4.19.295, 5.10.195, 5.15.132, 5.4.257, 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: b9bc8fbb2d416ce87f0342478dc9fcfd79f2c65f
CVE-2023-53612: kernel: hwmon: (coretemp) Simplify platform device handling
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.1 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-04T00:00:00+00:00

A NULL pointer dereference flaw was found in the Linux kernel's coretemp hardware monitoring driver in the platform device handling logic. A local privileged user who disables drivers_autoprobe for the platform bus can trigger this issue by initiating CPU hotplug operations, causing the driver to assume synchronous device binding when it does not occur. This results in a NULL pointer dereference leading to denial of service through a kernel crash or deadlock during suspend operations.

Statement: The coretemp driver uses an unconventional architecture where platform devices are dynamically created and destroyed from CPU hotplug notifiers. The code assumes that platform_device_add() will synchronously bind the driver and set drvdata before returning, but this assumption breaks when drivers_autoprobe is disabled for the platform bus. When hotplug events occur under these conditions, the driver dereferences uninitialized drvdata, causing a NULL pointer dereference. Additionally, the approach of managing platform devices from hotplug notifiers creates deadlock potential during system suspend and lockdep issues when other subsystems register CPU hotplug notifiers from platform bus notifiers.

Affected upstream versions: 4.10
Fixed upstream versions: 0, 5.10.173, 5.15.99, 5.4.235, 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: 4000384684f612b3645a944f6acde0e65ac370b8
CVE-2023-53613: kernel: dax: Fix dax_mapping_release() use after free
Component: kernel
Severity: Low
CWE: CWE-1341 (Multiple Releases of Same Resource or Handle)
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 use-after-free vulnerability was found in the Linux kernel's device-dax subsystem during mapping object cleanup. When removing a dax region provider, the child dax_mapping objects attempt to free their ID allocator after the parent dev_dax object has already been released. This causes ida_free to operate on freed memory, triggering lockdep warnings and potentially causing crashes or memory corruption, leading to denial of service.

Statement: The device-dax subsystem manages mappings of persistent memory regions. The parent-child relationship between dev_dax instances and their dax_mapping children follows the typical device model pattern: children hold references to parents while registered. However, dax_mapping objects were violating this pattern. When kobject delayed cleanup triggered dax_mapping_release (potentially seconds after the mapping was logically removed), it called ida_free on an ida structure that was part of the now-freed parent dev_dax object. The freed parent's memory could have been reallocated for other purposes, making the ida_free operate on arbitrary data structures. The issue manifests clearly under CONFIG_DEBUG_KOBJECT_RELEASE testing, which delays kobject cleanup to expose such bugs. Under normal conditions it creates a window where use-after-free could occur. The fix ensures dax_mapping holds an explicit reference on its parent that's only dropped during the final release callback.

Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.10.188, 5.15.121, 6.1.39, 6.3.13, 6.4.4, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 94a85474f5e3e518bdbf8c9f51cb343d734a04f7
CVE-2023-53615: kernel: scsi: qla2xxx: Fix deletion race condition
Component: kernel
Severity: Moderate
CWE: CWE-413 (Improper Resource Locking)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:H/A:H)
Public date: 2025-10-04T00:00:00+00:00

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

scsi: qla2xxx: Fix deletion race condition

System crash when using debug kernel due to link list corruption. The cause
of the link list corruption is due to session deletion was allowed to queue
up twice.  Here's the internal trace that show the same port was allowed to
double queue for deletion on different cpu.

20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1
20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1

Move the clearing/setting of deleted flag lock.

Statement: To trigger this vulnerability a user must be able to perform FC fabric management operations that cause session deletions. These kinds of operations generally require elevated permissions (ex. `CAP_SYS_ADMIN`).

Affected upstream versions: 4.11
Fixed upstream versions: 0, 5.10.195, 5.15.132, 5.4.258, 6.1.54, 6.5.4, 6.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a4628a5b98e4c6d905e1f7638242612d7db7d9c2
CVE-2023-53620: kernel: md: fix soft lockup in status_resync
Component: kernel
Severity: Moderate
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-07T00:00:00+00:00

A logic flaw was found in the Linux kernel Multiple Device (software RAID) status reporting, where concurrent updates to resynchronization progress can overflow an internal difference calculation. This can cause the progress bar routine to loop excessively and trigger a soft lockup. 

A local user could use this flaw to hang the system during array resynchronization, resulting in a denial of service.

Statement: status_resync() computes a difference between two fields that can change concurrently. If the subtraction wraps to a very large value, the code spends unbounded time emitting progress characters. The fix detects the inconsistent state and reports an “active” status without iterating, avoiding the long loop.

Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 6.1.30, 6.3.4, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b4acb6c3ede88d6b7d33742a09e63cfce5e7fb69
CVE-2023-53624: kernel: net/sched: sch_fq: fix integer overflow of "credit"
Component: kernel
Severity: Moderate
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-07T00:00:00+00:00

An integer overflow flaw was found in the Linux kernel network fair-queueing scheduler in the way the initial per-flow credit is set. If a configuration provides an excessively large initial quantum, the credit value can overflow to a negative number, leading to excessive scheduling and soft lockups. A local user with permission to configure queueing disciplines could use this flaw to degrade performance or hang the system, resulting in a denial of service.

Statement: The fair-queueing scheduler’s “initial quantum” could exceed the supported maximum for a signed integer, causing the first credit assignment to wrap to a large negative value for each new flow. The fix caps the “initial quantum” at the maximum supported value in the policy path so that the credit computation cannot overflow.

Affected upstream versions: 3.12
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: 4b8a05e3801661a0438fcd0cdef181030d966a5a
CVE-2023-53625: kernel: drm/i915/gvt: fix vgpu debugfs clean in remove
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
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-07T00:00:00+00:00

A NULL pointer dereference was found in the Linux kernel Intel i915 graphics driver's virtual GPU debugfs cleanup handling. 
A local user with privileges to unbind the i915 driver can trigger driver removal on systems with active virtual GPU instances, causing the cleanup path to attempt removing debugfs entries after the debugfs root has already been destroyed, which results in a NULL pointer dereference and denial of service through kernel crash.

Statement: The issue arises because of incorrect ordering in the driver removal sequence. When the i915 driver with GVT-g (GPU virtualization) support is unbound, the cleanup proceeds through multiple stages: driver removal, MDEV (mediated device) unregistration, and vGPU destruction. During vGPU destruction, the code unconditionally calls intel_gvt_debugfs_remove_vgpu() to clean up debugfs entries. However, at this point in the removal sequence, the DRM minor's debugfs root may have already been torn down. When debugfs_remove() attempts to lock the inode semaphore to recursively remove entries, it dereferences a NULL pointer (address 0x150, an offset into the destroyed debugfs inode structure), causing an immediate kernel oops. This occurs reliably on any system using GVT-g when the driver is unbound while virtual GPUs exist. The impact is strictly availability—the system crashes during driver removal. There is no memory corruption, information disclosure, or path to privilege escalation; the NULL dereference happens in lock acquisition code before any potentially dangerous operations could occur.

Affected upstream versions: 4.16
Fixed upstream versions: 0, 5.10.163, 5.15.87, 6.0.19, 6.1.5, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: af90f8b36d78544433a48a3eda6a5faeafacd0a1
CVE-2023-53628: kernel: drm/amdgpu: drop gfx_v11_0_cp_ecc_error_irq_funcs
Component: kernel
Severity: Moderate
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-07T00:00:00+00:00

A logic error was found in the Linux kernel amdgpu graphics driver's interrupt handling for GFX version 11 hardware. A local user with access to an AMD GPU can trigger a GPU device reset or suspend operation, causing the driver to attempt cleanup of a retired interrupt handler that no longer exists, which results in a kernel call trace and denial of service through system crash or GPU malfunction.

Statement: The issue arises because the gfx_v11_0_cp_ecc_error_irq interrupt handler was retired in GFX11 hardware, but the cleanup path in gfx_v11_0_hw_fini still attempts to disable this non-existent interrupt via amdgpu_irq_put. When GPU recovery or device suspend operations execute on affected hardware, the driver follows the standard teardown sequence and hits this stale reference, producing a call trace. Any workload that triggers GPU reset (such as through debugfs, recovery from GPU hang, or system suspend) will encounter this condition. The impact is limited to availability; there is no evidence of memory corruption or information disclosure, only disruption of GPU functionality.

Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.3.3, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 31b07aec4a2bdcab00770ea3a18efe49734ce153
CVE-2023-5363: openssl: Incorrect cipher key and IV length processing
Component: openssl
Severity: Moderate
CWE: CWE-325 (Missing Cryptographic Step)
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
Public date: 2023-10-24T15:00:00+00:00

A flaw was found in OpenSSL in how it processes key and initialization vector (IV) lengths. This issue can lead to potential truncation or overruns during the initialization of some symmetric ciphers. A truncation in the IV can result in non-uniqueness, which could result in loss of confidentiality for some cipher modes. Both truncations and overruns of the key and the IV will produce incorrect results and could, in some cases, trigger a memory exception.

Statement: The identified bug in the processing of key and initialization vector (IV) lengths within certain symmetric cipher modes poses a moderate severity risk due to its potential impact on data confidentiality and integrity. While the truncation or overreading of key and IV lengths could lead to incorrect cryptographic operations and potential memory exceptions, the probability of exploitation is mitigated by several factors. Firstly, the affected API was recently introduced, limiting its widespread adoption. Secondly, altering key and IV lengths is not a common operation in most cryptographic implementations. Furthermore, the likelihood of vulnerability is reduced by the necessity for both communication peers to be similarly affected for decryption failures to occur, which would likely be detected during testing.

Affected upstream versions: 3.0.0 < 3.0.12, 3.1.0 < 3.1.4
Fixed upstream versions: 3.0.12, 3.1.4
Upstream repository: https://git.openssl.org/gitweb/openssl.git
Upstream fix commit: 5f69f5c65e483928c4b28ed16af6e5742929f1ee
CVE-2023-53632: kernel: net/mlx5e: Take RTNL lock when needed before calling xdp_set_features()
Component: kernel
Severity: Moderate
CVSS v3: 5.3 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H)
Public date: 2025-10-07T00:00:00+00:00

A locking flaw in the Mellanox mlx5 Ethernet driver allowed calls to xdp_set_features() without holding the required rtnetlink (RTNL) lock. 

A local administrator switching device profiles (for example, from an uplink representor to a Network Interface Card profile) could trigger notifier paths without proper synchronization, leading to kernel warnings and potential denial of service (system instability or crash).

Statement: The issue stems from invoking XDP feature updates on a registered network device without the RTNL lock, which can race with network-device notifiers during profile changes in mlx5e. The fix ensures the RTNL lock is taken where required before updating XDP features.

Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.4.11, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 16b7775ae4389dd1e885732ea610321c64284e5f
CVE-2023-53634: kernel: bpf, arm64: Fixed a BTI error on returning to patched function
Component: kernel
Severity: Low
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-07T00:00:00+00:00

A control-flow integrity flaw was found in the Linux kernel on the arm64 architecture within the extended Berkeley Packet Filter trampoline return path. Returning to a patched function with an instruction sequence that fails the branch-target security check can trigger an exception and panic. 

A local user could use this flaw to crash the system when attaching programs that patch kernel call sites, resulting in a denial of service.

Statement: When the trampoline is configured to call the original function, it used an indirect branch back to the instruction after the call site. On arm64 systems with branch target enforcement, if that instruction is not one of the expected landing pads, the hardware raises an exception. The fix switches to a return instruction so the hardware recognizes a valid return target.

Affected upstream versions: 6.0
Fixed upstream versions: 0, 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: 8b9c64942ada229f52fe6f1b537a50f88b3c2673
CVE-2023-53639: kernel: wifi: ath6kl: reduce WARN to dev_dbg() in callback
Component: kernel
Severity: Moderate
CWE: CWE-366 (Race Condition within a Thread)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L)
Public date: 2025-10-07T00:00:00+00:00

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

wifi: ath6kl: reduce WARN to dev_dbg() in callback

The warn is triggered on a known race condition, documented in the code above
the test, that is correctly handled.  Using WARN() hinders automated testing.
Reducing severity.


Affected upstream versions: 3.9
Fixed upstream versions: 0, 4.14.315, 4.19.283, 5.10.180, 5.15.111, 5.4.243, 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: f2a429e6da37e32438a9adc250cc176a889c16a4
CVE-2023-53641: kernel: wifi: ath9k: hif_usb: fix memory leak of remain_skbs
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-07T00:00:00+00:00

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

wifi: ath9k: hif_usb: fix memory leak of remain_skbs

hif_dev->remain_skb is allocated and used exclusively in
ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is
processed and subsequently freed (in error paths) only during the next
call of ath9k_hif_usb_rx_stream().

So, if the urbs are deallocated between those two calls due to the device
deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()
is not called next time and the allocated remain_skb is leaked. Our local
Syzkaller instance was able to trigger that.

remain_skb makes sense when receiving two consecutive urbs which are
logically linked together, i.e. a specific data field from the first skb
indicates a cached skb to be allocated, memcpy'd with some data and
subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs
deallocation supposedly makes that link irrelevant so we need to free the
cached skb in those cases.

Fix the leak by introducing a function to explicitly free remain_skb (if
it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL
when it has not been allocated at all (hif_dev struct is kzalloced) or
when it has been processed in next call to ath9k_hif_usb_rx_stream().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Statement: Memory leak.

Affected upstream versions: 2.6.35
Fixed upstream versions: 0, 4.19.283, 5.10.180, 5.15.111, 5.4.243, 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: 6719e3797ec52cd144c8a5ba8aaab36674800585
CVE-2023-53645: kernel: bpf: Make bpf_refcount_acquire fallible for non-owning refs
Component: kernel
Severity: Moderate
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-07T00:00:00+00:00

A memory-safety flaw was found in the Linux kernel extended Berkeley Packet Filter (eBPF) subsystem in the way reference counts are acquired for objects after a failed tree insertion. When a program attempts to acquire a reference to a node that may already have been released, the reference count operation can proceed on a zero count, leading to a use-after-free and a crash. A local user could use this flaw to crash the system, resulting in a denial of service.

Statement: The change makes bpf_refcount_acquire return a nullable result and uses a “increment if not zero” primitive so that acquiring a reference on an object that may have been released fails safely. Verifier bookkeeping distinguishes owning from non-owning references so that callers with ownership still receive a guaranteed non-null result. This prevents reference count additions on an object whose lifetime ended after a failed container insertion.

Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.4.4, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d906d1b940b9dbf0a3e821d6b32a51c369273d91