huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-50532: kernel: scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()
Component: kernel
Severity: Low
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

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

scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()

In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,
sas_rphy_free() needs be called to free the resource allocated in
sas_end_device_alloc(). Otherwise a kernel crash will happen:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108
CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G        W          6.1.0-rc1+ #189
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x54/0x3d0
lr : device_del+0x37c/0x3d0
Call trace:
 device_del+0x54/0x3d0
 attribute_container_class_device_del+0x28/0x38
 transport_remove_classdev+0x6c/0x80
 attribute_container_device_trigger+0x108/0x110
 transport_remove_device+0x28/0x38
 sas_rphy_remove+0x50/0x78 [scsi_transport_sas]
 sas_port_delete+0x30/0x148 [scsi_transport_sas]
 do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
 device_for_each_child+0x68/0xb0
 sas_remove_children+0x30/0x50 [scsi_transport_sas]
 sas_rphy_remove+0x38/0x78 [scsi_transport_sas]
 sas_port_delete+0x30/0x148 [scsi_transport_sas]
 do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
 device_for_each_child+0x68/0xb0
 sas_remove_children+0x30/0x50 [scsi_transport_sas]
 sas_remove_host+0x20/0x38 [scsi_transport_sas]
 scsih_remove+0xd8/0x420 [mpt3sas]

Because transport_add_device() is not called when sas_rphy_add() fails, the
device is not added. When sas_rphy_remove() is subsequently called to
remove the device in the remove() path, a NULL pointer dereference happens.


Affected upstream versions: 3.8
Fixed upstream versions: 0, 5.10.163, 5.15.86, 5.4.229, 6.0.16, 6.1.2, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d60000cb1195a464080b0efb4949daf7594e0020
CVE-2022-50534: kernel: dm thin: Use last transaction's pmd->root when commit failed
Component: kernel
Severity: Moderate
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-07T00:00:00+00:00

A metadata handling flaw was found in the Linux kernel device-mapper thin provisioning driver. After a failed metadata commit, the in-memory root pointer could reference a mixed set of fresh and stale tree nodes. Subsequent lookups may loop or stall. 

A local user could use this flaw to cause the thin-pool worker to hang, resulting in a denial of service on the host.

Statement: If a transaction partially writes updated nodes and then fails, the pointer used for lookups may point into a broken tree. The correction reloads the last known good root at open time when a prior commit failed, so later reads do not traverse a corrupted path.

Affected upstream versions: 3.2
Fixed upstream versions: 0, 4.14.303, 4.19.270, 4.9.337, 5.10.163, 5.15.87, 5.4.229, 6.0.18, 6.1.4, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b35a22760aa5008d82533e59b0f0b5eb1b02d4e5
CVE-2022-50535: kernel: drm/amd/display: Fix potential null-deref in dm_resume
Component: kernel
Severity: Low
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

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

drm/amd/display: Fix potential null-deref in dm_resume

[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null

[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.


Affected upstream versions: 4.15
Fixed upstream versions: 0, 4.19.276, 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: fd79b61af2782f8875c78f50cdb8630ec43e2990
CVE-2022-50536: kernel: bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
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 reference-count flaw was found in the Linux kernel Berkeley Packet Filter (BPF) sockmap implementation. When processing messages with remaining data, the same Transmission Control Protocol (TCP) socket reference could be released more than once. 
A local user running BPF sockmap programs could use this flaw to trigger a use-after-free and crash the system, resulting in a denial of service.

Statement: The flaw arises because the verdict state was not reset at boundaries where additional message data arrives, causing the same socket reference to be dropped more than once. The fix resets the internal verdict state when handling continued data, preventing double release.

Affected upstream versions: 5.4.157 < 5.4.229, 5.10.77 < 5.10.163, 5.14.16 < 5.15, 5.15
Fixed upstream versions: 0, 5.10.163, 5.15, 5.15.86, 5.4.229, 6.0.16, 6.1.2, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7508b9f4daac4ec7dfe0b6fb2d688b1c1c105e10
CVE-2022-50541: kernel: dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow
Component: kernel
Severity: Moderate
CVSS v3: 6.3 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H)
Public date: 2025-10-07T00:00:00+00:00

A counter-overflow flaw was found in the Linux kernel Texas Instruments K3 Universal Direct Memory Access (UDMA) driver. During long data transfers exceeding four gigabytes, the hardware byte-count registers could wrap and misreport progress, causing the transfer to hang indefinitely. 
A local user could use this flaw to cause a denial of service due to a stalled input/output operation.

Statement: The real-time byte counters used for tracking DMA progress were 32-bit values that overflowed during large transfers. The fix subtracts completed bytes after each transaction to prevent counter wrap and maintain accurate progress tracking.

Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.15.75, 5.19.17, 6.0.3, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d68da10b0cceb4177b653833e794b2923a4ffbd7
CVE-2022-50543: kernel: RDMA/rxe: Fix mr->map double free
Component: kernel
Severity: Moderate
CWE: CWE-1341 (Multiple Releases of Same Resource or Handle)
CVSS v3: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-10-07T00:00:00+00:00

A double-free vulnerability was found in the Linux kernel RDMA RXE (soft-RoCE) driver's memory region handling. A local user with access to RDMA userspace verbs can register a memory region with parameters that cause initialization to fail, triggering error handling code that frees the mr->map structure twice, which leads to memory corruption and can result in denial of service via kernel crash or potentially privilege escalation through heap manipulation.

Statement: The issue arises because of incorrect error handling in the memory region registration path. When rxe_reg_user_mr() calls rxe_mr_init_user() and initialization fails, the error path frees the mr->map structure. However, the cleanup then calls rxe_mr_cleanup() through __rxe_cleanup(), which attempts to free mr->map again, resulting in a double-free. This vulnerability was introduced when a previous fix for duplicate mapping tables was reverted, inadvertently reintroducing the double-free condition. Under normal circumstances, a local user with permissions to use RDMA verbs (typically requiring membership in the rdma group or CAP_IPC_LOCK capability) can trigger this by registering user memory regions with specific parameters that cause initialization failure. Double-free vulnerabilities are well-known memory corruption primitives; while direct exploitation for privilege escalation requires understanding kernel heap layout, they provide attackers with a foundation for more sophisticated attacks beyond simple denial of service.

Affected upstream versions: 5.19.4 < 5.20, 6.0
Fixed upstream versions: 0, 5.20, 6.0.16, 6.1.2, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6ce577f09013206e36e674cd27da3707b2278268
CVE-2022-50544: kernel: usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
Component: kernel
Severity: Low
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:

usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()

xhci_alloc_stream_info() allocates stream context array for stream_info
->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,
stream_info->stream_ctx_array is not released, which will lead to a
memory leak.

We can fix it by releasing the stream_info->stream_ctx_array with
xhci_free_stream_ctx() on the error path to avoid the potential memory
leak.


Affected upstream versions: 2.6.35
Fixed upstream versions: 0, 4.14.296, 4.19.262, 4.9.331, 5.10.150, 5.15.75, 5.19.17, 5.4.220, 6.0.3, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7fc6bab3413e6a42bb1264ff7c9149808c93a4c7
CVE-2022-50546: kernel: ext4: fix uninititialized value in 'ext4_evict_inode'
Component: kernel
Severity: Low
CWE: CWE-908 (Use of Uninitialized 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-07T00:00:00+00:00

An uninitialized variable flaw was found in the Linux kernel's ext4 filesystem in the inode eviction path. 
A local user can trigger this issue by creating filesystem operations that cause inode allocation to fail before the i_flags field is initialized, followed by inode cleanup that attempts to read the uninitialized field. This causes the kernel to access uninitialized memory, resulting in unpredictable behavior and denial of service through a kernel crash.

Statement: The ext4_alloc_inode function allocates memory for new inodes but fails to initialize the ei->i_flags field. When __ext4_new_inode encounters an error before setting i_flags and calls iput to clean up, the subsequent ext4_evict_inode function attempts to read the uninitialized i_flags value. This accesses undefined memory contents, triggering KMSAN (Kernel Memory Sanitizer) warnings and potentially causing kernel crashes or unpredictable behavior. The issue occurs during normal filesystem operations like mkdir or mknod when inode allocation fails partway through, which can happen under memory pressure or filesystem corruption. Any local user performing filesystem operations on ext4 volumes can potentially trigger this condition.

Affected upstream versions: 5.10.163 < 5.10.164, 5.15.61 < 5.15.87, 5.18.18 < 5.19, 5.19.2 < 5.20, 6.0
Fixed upstream versions: 0, 5.10.164, 5.15.87, 5.19, 5.20, 6.0.18, 6.1.4, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f0bffdcc7cb14598af2aa706f1e0f2a9054154ba
CVE-2022-50549: kernel: dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata
Component: kernel
Severity: Low
CWE: CWE-833 (Deadlock)
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 ABBA deadlock flaw was found in the Linux kernel's device-mapper thin provisioning subsystem between the memory reclaim path and metadata abort handling. A local user can trigger this issue by initiating cache drop operations while dm-thin operations are active, causing process P1 to hold shrinker_rwsem and wait for pmd->root_lock while process P2 holds pmd->root_lock and waits for shrinker_rwsem during metadata abort. This results in a deadlock manifesting as hung tasks and system unresponsiveness, leading to denial of service.

Statement: The deadlock occurs through a specific interaction between memory management and device-mapper operations. When cache is dropped (via /proc/sys/vm/drop_caches), the shrink_slab path acquires shrinker_rwsem for reading, then processes filesystem operations that may involve dm-thin devices. Concurrently, when dm-thin metadata operations fail, the dm_pool_abort_metadata function acquires pmd->root_lock, destroys the block manager (which unregisters a shrinker), and attempts to acquire shrinker_rwsem for writing. Meanwhile, thin_map operations acquire pmd->root_lock for reading. This creates an ABBA deadlock: P1 holds shrinker_rwsem→waits for pmd->root_lock, P2 holds pmd->root_lock→waits for shrinker_rwsem.

Affected upstream versions: 3.6
Fixed upstream versions: 0, 5.10.163, 5.15.87, 5.4.229, 6.0.18, 6.1.4, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 200aa33b5d781e7c0fa6c0c7db9dbcc3f574ce8f
CVE-2022-50554: kernel: blk-mq: avoid double ->queue_rq() because of early timeout
Component: kernel
Severity: Moderate
CWE: CWE-820 (Missing Synchronization)
CVSS v3: 5.2 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-10-07T00:00:00+00:00

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

blk-mq: avoid double ->queue_rq() because of early timeout

David Jeffery found one double ->queue_rq() issue, so far it can
be triggered in VM use case because of long vmexit latency or preempt
latency of vCPU pthread or long page fault in vCPU pthread, then block
IO req could be timed out before queuing the request to hardware but after
calling blk_mq_start_request() during ->queue_rq(), then timeout handler
may handle it by requeue, then double ->queue_rq() is caused, and kernel
panic.

So far, it is driver's responsibility to cover the race between timeout
and completion, so it seems supposed to be solved in driver in theory,
given driver has enough knowledge.

But it is really one common problem, lots of driver could have similar
issue, and could be hard to fix all affected drivers, even it isn't easy
for driver to handle the race. So David suggests this patch by draining
in-progress ->queue_rq() for solving this issue.


Affected upstream versions: 4.18
Fixed upstream versions: 0, 6.0.16, 6.1.2, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7a73c54a3750895888ab586896736c9434e062a1
CVE-2022-50555: kernel: tipc: fix a null-ptr-deref in tipc_topsrv_accept
Component: kernel
Severity: Low
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

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

tipc: fix a null-ptr-deref in tipc_topsrv_accept

syzbot found a crash in tipc_topsrv_accept:

  KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
  Workqueue: tipc_rcv tipc_topsrv_accept
  RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487
  Call Trace:
   <TASK>
   tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460
   process_one_work+0x991/0x1610 kernel/workqueue.c:2289
   worker_thread+0x665/0x1080 kernel/workqueue.c:2436
   kthread+0x2e4/0x3a0 kernel/kthread.c:376
   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

It was caused by srv->listener that might be set to null by
tipc_topsrv_stop() in net .exit whereas it's still used in
tipc_topsrv_accept() worker.

srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so add
a check for srv->listener under srv->idr_lock in tipc_topsrv_accept() to
avoid the null-ptr-deref. To ensure the lsock is not released during the
tipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()
where it's waiting until the tipc_topsrv_accept worker to be done.

Note that sk_callback_lock is used to protect sk->sk_user_data instead of
srv->listener, and it should check srv in tipc_topsrv_listener_data_ready()
instead. This also ensures that no more tipc_topsrv_accept worker will be
started after tipc_conn_close() is called in tipc_topsrv_stop() where it
sets sk->sk_user_data to null.


Affected upstream versions: 4.17
Fixed upstream versions: 0, 4.19.264, 5.10.153, 5.15.77, 5.4.223, 6.0.7, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ce69bdac2310152bb70845024d5d704c52aabfc3
CVE-2022-50556: kernel: drm: Fix potential null-ptr-deref due to drmm_mode_config_init()
Component: kernel
Severity: Low
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-22T00:00:00+00:00

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

drm: Fix potential null-ptr-deref due to drmm_mode_config_init()

drmm_mode_config_init() will call drm_mode_create_standard_properties()
and won't check the ret value. When drm_mode_create_standard_properties()
failed due to alloc, property will be a NULL pointer and may causes the
null-ptr-deref. Fix the null-ptr-deref by adding the ret value check.

Found null-ptr-deref while testing insert module bochs:
general protection fault, probably for non-canonical address
    0xdffffc000000000c: 0000 [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]
CPU: 3 PID: 249 Comm: modprobe Not tainted 6.1.0-rc1+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:drm_object_attach_property+0x73/0x3c0 [drm]
Call Trace:
 <TASK>
 __drm_connector_init+0xb6c/0x1100 [drm]
 bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs]
 pci_device_probe+0x17d/0x340
 really_probe+0x1db/0x5d0
 __driver_probe_device+0x1e7/0x250
 driver_probe_device+0x4a/0x120
 __driver_attach+0xcd/0x2c0
 bus_for_each_dev+0x11a/0x1b0
 bus_add_driver+0x3d7/0x500
 driver_register+0x18e/0x320
 do_one_initcall+0xc4/0x3e0
 do_init_module+0x1b4/0x630
 load_module+0x5dca/0x7230
 __do_sys_finit_module+0x100/0x170
 do_syscall_64+0x3f/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7ff65af9f839


Affected upstream versions: 4.0
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: 5ae70041a6d7de62a0cdb2bbcfe0c9cf753035d0
CVE-2022-50562: kernel: tpm: acpi: Call acpi_put_table() to fix memory leak
Component: kernel
Severity: Low
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-22T00:00:00+00:00

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

tpm: acpi: Call acpi_put_table() to fix memory leak

The start and length of the event log area are obtained from
TPM2 or TCPA table, so we call acpi_get_table() to get the
ACPI information, but the acpi_get_table() should be coupled with
acpi_put_table() to release the ACPI memory, add the acpi_put_table()
properly to fix the memory leak.

While we are at it, remove the redundant empty line at the
end of the tpm_read_log_acpi().


Affected upstream versions: 4.18
Fixed upstream versions: 0, 5.10.163, 5.15.87, 6.0.17, 6.1.3, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8ddc48068ac85740d3d5f9f3b0b323e733a35b33
CVE-2022-50569: kernel: xfrm: Update ipcomp_scratches with NULL when freed
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-22T00:00:00+00:00

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

xfrm: Update ipcomp_scratches with NULL when freed

Currently if ipcomp_alloc_scratches() fails to allocate memory
ipcomp_scratches holds obsolete address. So when we try to free the
percpu scratches using ipcomp_free_scratches() it tries to vfree non
existent vm area. Described below:

static void * __percpu *ipcomp_alloc_scratches(void)
{
        ...
        scratches = alloc_percpu(void *);
        if (!scratches)
                return NULL;
ipcomp_scratches does not know about this allocation failure.
Therefore holding the old obsolete address.
        ...
}

So when we free,

static void ipcomp_free_scratches(void)
{
        ...
        scratches = ipcomp_scratches;
Assigning obsolete address from ipcomp_scratches

        if (!scratches)
                return;

        for_each_possible_cpu(i)
               vfree(*per_cpu_ptr(scratches, i));
Trying to free non existent page, causing warning: trying to vfree
existent vm area.
        ...
}

Fix this breakage by updating ipcomp_scrtches with NULL when scratches
is freed

Statement: The global ipcomp_scratches could retain a stale pointer when allocation failed or after free, causing ipcomp_free_scratches() to iterate and call vfree() on already-freed/non-existent per-CPU pages—effectively a double free/invalid free leading to warnings or crashes. The fix sets ipcomp_scratches = NULL after free_percpu(scratches), preventing subsequent frees of stale memory. Privileged access to XFRM/IPComp setup is typically required.

Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 4.14.296, 4.19.262, 4.9.331, 5.10.150, 5.15.75, 5.19.17, 5.4.220, 6.0.3, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: debca61df6bc2f65e020656c9c5b878d6b38d30f
CVE-2022-50578: kernel: Linux kernel: Memory leak in __class_register()
Component: kernel
Severity: Low
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-22T00:00:00+00:00

A flaw was found in the Linux kernel. This vulnerability allows a local attacker to cause a denial of service via a memory leak in the driver system's `__class_register()` function.


Affected upstream versions: 4.10
Fixed upstream versions: 0, 4.14.303, 4.19.270, 5.10.163, 5.15.86, 5.4.229, 6.0.16, 6.1.2, 6.2
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4efa5443817c1b6de22d401aeca5b2481e835f8c
CVE-2022-50580: kernel: blk-throttle: prevent overflow while calculating wait time
Component: kernel
Severity: Low
CWE: CWE-190 (Integer Overflow or Wraparound)
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-22T00:00:00+00:00

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

blk-throttle: prevent overflow while calculating wait time

There is a problem found by code review in tg_with_in_bps_limit() that
'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem by
calling mul_u64_u64_div_u64() instead.


Affected upstream versions: 2.6.37
Fixed upstream versions: 0, 5.10.150, 5.15.75, 5.19.17, 6.0.3, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 19c010ae44f0ce52b5436080492a61a092ee0cf4