huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-50486: kernel: net: ethernet: ti: Fix return type of netcp_ndo_start_xmit()
Component: kernel
Severity: Moderate
CWE: CWE-843 (Access of Resource Using Incompatible Type ('Type Confusion'))
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 type confusion flaw was found in the Linux kernel's Texas Instruments NETCP Ethernet driver in the packet transmit function signature. 
A local user can trigger this issue on systems with kernel Control Flow Integrity enabled, where the incorrect return type of the ndo_start_xmit function causes CFI validation failures during indirect function calls. This results in either a kernel panic or thread termination, leading to denial of service.

Statement: The netcp_ndo_start_xmit function is declared with a return type of 'int' instead of the expected 'netdev_tx_t' enum. When CONFIG_CFI_CLANG is enabled, the kernel validates indirect function call targets against their expected prototypes to prevent control-flow hijacking attacks. The type mismatch causes CFI to reject the call, triggering either a kernel panic or killing the calling thread. This only affects systems compiled with Clang's CFI support enabled and running on Texas Instruments NETCP hardware. Without CFI enabled, the incorrect return type is harmless due to ABI compatibility between int and the enum.

Affected upstream versions: 4.0
Fixed upstream versions: 0, 4.14.303, 4.19.270, 4.9.337, 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: a447479ea2cf35603b5739ea947885024b901222
CVE-2022-50489: kernel: drm/mipi-dsi: Detach devices when removing the host
Component: kernel
Severity: Low
CWE: CWE-459 (Incomplete Cleanup)
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 leak flaw was found in the Linux kernel's MIPI-DSI host driver in the device removal logic. A local user can trigger this issue by unregistering a MIPI-DSI host, causing the cleanup code to unregister all attached devices without first detaching them. This prevents the host from performing proper cleanup operations, resulting in resource leaks including memory, references, and hardware state, leading to denial of service through resource exhaustion.

Statement: The mipi_dsi_host_unregister function iterates through all MIPI-DSI devices attached to the host and calls device_unregister on each. However, it skips the detachment step that would normally invoke the host's detach callback, allowing the host driver to release resources associated with that device. This means allocated memory, DMA mappings, clock references, power domain associations, and other resources remain allocated even after the device is unregistered. Since the host is being removed, these resources cannot be cleaned up later and represent permanent leaks until system reboot.

Affected upstream versions: 3.14
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: c202cda08cd5693645d4990ad1eb2e8068a884ec
CVE-2022-50491: kernel: coresight: cti: Fix hang in cti_disable_hw()
Component: kernel
Severity: Low
CWE: CWE-1322 (Use of Blocking Code in Single-threaded, Non-blocking Context)
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 context violation bug was found in the Linux kernel's CoreSight CTI (Cross Trigger Interface) driver in the hardware enable/disable functions. These functions are called from atomic context but attempt runtime PM operations that can sleep when communicating with firmware. This causes "sleeping function called from invalid context" errors and system hangs when enabling CoreSight tracing, particularly on ARM Juno platforms, resulting in denial of service.

Statement: The CTI component coordinates debugging across multiple cores. When perf enables ETM (Embedded Trace Macrocell) tracing, it builds a trace path and enables each component along that path—including CTI devices. This happens under spinlocks in the perf event scheduling code, creating an atomic context where sleeping is forbidden. The cti_enable_hw and cti_disable_hw functions were calling pm_runtime_get and pm_runtime_put to manage power. These runtime PM calls can communicate with firmware (like ARM SCMI) to control clocks and power domains. Firmware communication typically involves waiting for responses, which means sleeping. Sleeping in atomic context triggers kernel warnings and can cause complete system hangs. The issue became more visible after a revert of SCMI power domain changes made the sleep more likely. The solution: remove the PM calls entirely from these functions. The runtime PM has already been handled at a higher level when building the trace path, so these redundant calls were both wrong and unnecessary.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.154, 5.15.77, 6.0.7, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e33ce54cef5d429430e3b1ae5c8ee4f4103c4fdc
CVE-2022-50493: kernel: scsi: qla2xxx: Fix crash when I/O abort times out
Component: kernel
Severity: Moderate
CWE: CWE-820 (Missing Synchronization)
CVSS v3: 4 (CVSS:3.1/AV:P/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:

scsi: qla2xxx: Fix crash when I/O abort times out

While performing CPU hotplug, a crash with the following stack was seen:

Call Trace:
     qla24xx_process_response_queue+0x42a/0x970 [qla2xxx]
     qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx]
     qla_nvme_post_cmd+0x166/0x240 [qla2xxx]
     nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc]
     blk_mq_dispatch_rq_list+0x17b/0x610
     __blk_mq_sched_dispatch_requests+0xb0/0x140
     blk_mq_sched_dispatch_requests+0x30/0x60
     __blk_mq_run_hw_queue+0x35/0x90
     __blk_mq_delay_run_hw_queue+0x161/0x180
     blk_execute_rq+0xbe/0x160
     __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core]
     nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics]
     nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc]
     nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc]
     process_one_work+0x1e8/0x3c0

On abort timeout, completion was called without checking if the I/O was
already completed.

Verify that I/O and abort request are indeed outstanding before attempting
completion.


Affected upstream versions: 5.3.17 < 5.4, 5.4.4 < 5.5, 5.5
Fixed upstream versions: 0, 5.10.258, 5.15.86, 5.4, 5.5, 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: 5f730e489e741c28fe6a5b3308e33c094462acb0
CVE-2022-50496: kernel: dm cache: Fix UAF in destroy()
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-10-04T00:00:00+00:00

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

dm cache: Fix UAF in destroy()

Dm_cache also has the same UAF problem when dm_resume()
and dm_destroy() are concurrent.

Therefore, cancelling timer again in destroy().


Affected upstream versions: 3.9
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: 034cbc8d3b47a56acd89453c29632a9c117de09d
CVE-2022-50504: kernel: powerpc/rtas: avoid scheduling in rtas_os_term()
Component: kernel
Severity: Low
CWE: CWE-663 (Use of a Non-reentrant Function in a Concurrent Context)
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-04T00:00:00+00:00

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

powerpc/rtas: avoid scheduling in rtas_os_term()

It's unsafe to use rtas_busy_delay() to handle a busy status from
the ibm,os-term RTAS function in rtas_os_term():

Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
BUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0
preempt_count: 2, expected: 0
CPU: 7 PID: 1 Comm: swapper/0 Tainted: G      D            6.0.0-rc5-02182-gf8553a572277-dirty #9
Call Trace:
[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)
[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0
[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0
[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4
[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68
[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50
[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0
[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0
[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0
[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420
[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200

Use rtas_busy_delay_time() instead, which signals without side effects
whether to attempt the ibm,os-term RTAS call again.

Statement: This vulnerability is rated as LOW with limited impact on availability. This limited impact is due to the conditions during which the flaw appears; specifically, it occurs during system panic handling, meaning it does not create a new DoS condition, but may lead to less stable panic handling.

Affected upstream versions: 2.6.18
Fixed upstream versions: 0, 4.14.303, 4.19.270, 4.9.337, 5.10.163, 5.15.87, 5.4.229, 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: f413135b337c4e90c1e593c6613f8717e17bc724
CVE-2022-50506: kernel: drbd: only clone bio if we have a backing device
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-04T00:00:00+00:00

A NULL pointer dereference was found in the Linux kernel Distributed Replicated Block Device driver's I/O request handling. A local user with privileges to perform I/O operations on a DRBD block device can trigger I/O requests when the DRBD device is configured in diskless mode (no local backing device), causing the driver to dereference a NULL pointer when attempting to access the backing device structure, which results in denial of service through kernel crash.

Statement: The issue arises because of a code refactoring that moved device structure access earlier in the I/O request path without adding proper NULL validation. When drbd_req_new() processes a new I/O request, it attempts to clone the bio and access device->ldev->backing_bdev to set up the backing device information. However, when DRBD is configured in diskless mode (a valid configuration where DRBD acts purely as a network replication layer without local storage), the ldev pointer is NULL. The code lacks a check for this condition before dereferencing the pointer chain, causing an immediate kernel NULL pointer dereference. This occurs reliably whenever I/O is attempted on a diskless DRBD device. While this causes complete system failure through kernel panic, NULL pointer dereferences on modern kernels with memory protection mechanisms cannot be exploited for code execution or information disclosure, only denial of service.

Affected upstream versions: 5.18
Fixed upstream versions: 0, 6.0.6, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 05580a3bbf3cec677cb00a85dfeb21d6a9b48eaf
CVE-2022-50510: kernel: perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()
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 resource-handling flaw was found in the Linux kernel performance monitoring driver for ARM System Memory Management Unit version 3 in the way hotplug callbacks are registered during driver initialization. If driver registration fails, previously added CPU hotplug callbacks are not removed, leaving leaked callbacks behind. A local user could use this flaw to destabilize the system, resulting in a denial of service.

Statement: arm_smmu_pmu_init() added multi-CPU hotplug callbacks but did not remove them on a subsequent platform driver registration failure. The correction removes the registered callbacks in the failure path so that no dangling hotplug handlers remain after an init error.

Affected upstream versions: 5.2
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: d69bdb61d577297d3851fc9f6403574bf73ef41f
CVE-2022-50511: kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font
Component: kernel
Severity: Low
CWE: CWE-1335 (Incorrect Bitwise Shift of Integer)
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-07T00:00:00+00:00

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

lib/fonts: fix undefined behavior in bit shift for get_default_font

Shifting signed 32-bit value by 31 bits is undefined, so changing
significant bit to unsigned.  The UBSAN warning calltrace like below:

UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20
left shift of 1 by 31 places cannot be represented in type 'int'
 <TASK>
 dump_stack_lvl+0x7d/0xa5
 dump_stack+0x15/0x1b
 ubsan_epilogue+0xe/0x4e
 __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c
 get_default_font+0x1c7/0x1f0
 fbcon_startup+0x347/0x3a0
 do_take_over_console+0xce/0x270
 do_fbcon_takeover+0xa1/0x170
 do_fb_registered+0x2a8/0x340
 fbcon_fb_registered+0x47/0xe0
 register_framebuffer+0x294/0x4a0
 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]
 drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]
 drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]
 drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]
 bochs_pci_probe+0x6ca/0x772 [bochs]
 local_pci_probe+0x4d/0xb0
 pci_device_probe+0x119/0x320
 really_probe+0x181/0x550
 __driver_probe_device+0xc6/0x220
 driver_probe_device+0x32/0x100
 __driver_attach+0x195/0x200
 bus_for_each_dev+0xbb/0x120
 driver_attach+0x27/0x30
 bus_add_driver+0x22e/0x2f0
 driver_register+0xa9/0x190
 __pci_register_driver+0x90/0xa0
 bochs_pci_driver_init+0x52/0x1000 [bochs]
 do_one_initcall+0x76/0x430
 do_init_module+0x61/0x28a
 load_module+0x1f82/0x2e50
 __do_sys_finit_module+0xf8/0x190
 __x64_sys_finit_module+0x23/0x30
 do_syscall_64+0x58/0x80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
 </TASK>

Statement: The change fixes undefined behaviour from shifting a signed 32-bit value by a high bit position (UBSAN: shift-out-of-bounds) by switching the literal to an unsigned type.
In practice this triggered UBSAN warnings and can crash under some configurations during framebuffer/font selection (module init / fbcon startup).
Reproducing requires loading the affected code path (e.g. initializing the framebuffer or loading the driver that calls get_default_font).
For the CVSS the PR:H, because triggering the problematic code path requires privileged/local operations (module/driver or framebuffer initialization).

Affected upstream versions: 2.6.23
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: e039929e36818507e90901edae87f6fa8bc81093
CVE-2022-50512: kernel: ext4: fix potential memory leak in ext4_fc_record_regions()
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:

ext4: fix potential memory leak in ext4_fc_record_regions()

As krealloc may return NULL, in this case 'state->fc_regions' may not be
freed by krealloc, but 'state->fc_regions' already set NULL. Then will
lead to 'state->fc_regions' memory leak.


Affected upstream versions: 5.10
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: 2cfb769d60a2a57eb3566765428b6131cd16dcfe
CVE-2022-50515: kernel: drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue()
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:

drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue()

If construction of the array of work queues to handle hpd_rx_irq offload
work fails, we need to unwind. Destroy all the created workqueues and
the allocated memory for the hpd_rx_irq_offload_work_queue struct array.


Affected upstream versions: 5.15.58 < 5.15.75, 5.16
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: 3ba3814c00a4817eb1cd31eff08d921c40e5f3a4
CVE-2022-50520: kernel: drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()
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-07T00:00:00+00:00

A reference leak flaw was found in the Linux kernel's Radeon graphics driver in the BIOS retrieval logic. 
A local user on systems with AMD Radeon graphics hardware can trigger this issue when the driver searches for ACPI firmware tables and exits the search loop with an acquired PCI device reference that is never released. This results in a permanent reference leak preventing proper device cleanup and leading to resource exhaustion or denial of service.

Statement: The radeon_atrm_get_bios function uses pci_get_class to iterate through PCI devices searching for compatible ACPI firmware tables. The pci_get_class function returns a device pointer with an incremented reference count and decrements the reference for the previous device. When the loop breaks with a non-NULL pdev (having found a suitable device), the code fails to call pci_dev_put to decrement the reference count. This violates PCI device reference counting rules and prevents the device from being properly cleaned up even when the driver is unloaded.

Affected upstream versions: 3.2.29 < 3.3, 3.4.12 < 3.5, 3.5.5 < 3.6, 3.2.60 < 3.3, 3.6
Fixed upstream versions: 0, 3.3, 3.5, 3.6, 4.14.303, 4.19.270, 4.9.337, 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: 6f28c7f67af4ef9bca580ab67ae2d4511797af56
CVE-2022-50527: kernel: drm/amdgpu: Fix size validation for non-exclusive domains (v4)
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

A NULL pointer dereference flaw was found in the Linux kernel's AMD GPU driver in the buffer object size validation logic. 
A local user on systems with AMD graphics hardware can trigger this issue by requesting memory allocation in non-exclusive domains when the Translation Table Manager domain manager has not been initialized. This causes the kernel to dereference a NULL pointer when validating buffer sizes, resulting in a kernel crash and denial of service.

Statement: The amdgpu_bo_validate_size function attempts to validate buffer allocations by checking domain manager constraints, but fails to verify that the domain manager pointer is non-NULL before dereferencing it. When a buffer object is created with a domain configuration that lacks an initialized manager, particularly for the Graphics Translation Table domain, the code accesses the NULL manager pointer, triggering an immediate kernel oops. This occurs during graphics memory allocation operations, which any local user with access to AMD GPU devices can initiate through normal graphics API calls

Affected upstream versions: 4.2
Fixed upstream versions: 0, 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: 80546eef216854a7bd47e39e828f04b406c00599
CVE-2022-50528: kernel: drm/amdkfd: Fix memory leakage
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:

drm/amdkfd: Fix memory leakage

This patch fixes potential memory leakage and seg fault
in  _gpuvm_import_dmabuf() function


Affected upstream versions: 5.14
Fixed upstream versions: 0, 5.15.86, 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: 8876793e56ec69b3be2a883b4bc440df3dbb1865
CVE-2022-50530: kernel: blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()
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

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

blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()

Our syzkaller report a null pointer dereference, root cause is
following:

__blk_mq_alloc_map_and_rqs
 set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs
  blk_mq_alloc_map_and_rqs
   blk_mq_alloc_rqs
    // failed due to oom
    alloc_pages_node
    // set->tags[hctx_idx] is still NULL
    blk_mq_free_rqs
     drv_tags = set->tags[hctx_idx];
     // null pointer dereference is triggered
     blk_mq_clear_rq_mapping(drv_tags, ...)

This is because commit 63064be150e4 ("blk-mq:
Add blk_mq_alloc_map_and_rqs()") merged the two steps:

1) set->tags[hctx_idx] = blk_mq_alloc_rq_map()
2) blk_mq_alloc_rqs(..., set->tags[hctx_idx])

into one step:

set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs()

Since tags is not initialized yet in this case, fix the problem by
checking if tags is NULL pointer in blk_mq_clear_rq_mapping().


Affected upstream versions: 5.16
Fixed upstream versions: 0, 6.0.6, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 6a440e6d04431e774dc084abe88c106e2a474c1a
CVE-2022-50531: kernel: Linux kernel (TIPC): Information disclosure via uninitialized memory in tipc_topsrv_kern_subscr
Component: kernel
Severity: Low
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 3.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N)
Public date: 2025-10-07T00:00:00+00:00

A flaw was found in the Linux kernel's Transparent Inter-Process Communication (TIPC) protocol. This vulnerability allows a local user to disclose sensitive information due to four uninitialized bytes in the sub.usr_handle field within the tipc_topsrv_kern_subscr() function. When a user issues a setsockopt call with SOL_TIPC, these uninitialized bytes can be leaked, leading to information disclosure.


Affected upstream versions: 4.17
Fixed upstream versions: 0, 4.19.264, 5.10.152, 5.15.76, 5.4.221, 6.0.6, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3d1b83ff7b6575a4e41283203e6b2e25ea700cd7