huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-50452: kernel: net: sched: cake: fix null pointer access issue when cake_init() fails
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
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-01T00:00:00+00:00

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

net: sched: cake: fix null pointer access issue when cake_init() fails

When the default qdisc is cake, if the qdisc of dev_queue fails to be
inited during mqprio_init(), cake_reset() is invoked to clear
resources. In this case, the tins is NULL, and it will cause gpf issue.

The process is as follows:
qdisc_create_dflt()
	cake_init()
		q->tins = kvcalloc(...)        --->failed, q->tins is NULL
	...
	qdisc_put()
		...
		cake_reset()
			...
			cake_dequeue_one()
				b = &q->tins[...]   --->q->tins is NULL

The following is the Call Trace information:
general protection fault, probably for non-canonical address
0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:cake_dequeue_one+0xc9/0x3c0
Call Trace:
<TASK>
cake_reset+0xb1/0x140
qdisc_reset+0xed/0x6f0
qdisc_destroy+0x82/0x4c0
qdisc_put+0x9e/0xb0
qdisc_create_dflt+0x2c3/0x4a0
mqprio_init+0xa71/0x1760
qdisc_create+0x3eb/0x1000
tc_modify_qdisc+0x408/0x1720
rtnetlink_rcv_msg+0x38e/0xac0
netlink_rcv_skb+0x12d/0x3a0
netlink_unicast+0x4a2/0x740
netlink_sendmsg+0x826/0xcc0
sock_sendmsg+0xc5/0x100
____sys_sendmsg+0x583/0x690
___sys_sendmsg+0xe8/0x160
__sys_sendmsg+0xbf/0x160
do_syscall_64+0x35/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f89e5122d04
</TASK>


Affected upstream versions: 4.19
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: 86aa1390898146f1de277bb6d2a8ed7fc7a43f12
CVE-2022-50453: kernel: gpiolib: cdev: fix NULL-pointer dereferences
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-01T00:00:00+00:00

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

gpiolib: cdev: fix NULL-pointer dereferences

There are several places where we can crash the kernel by requesting
lines, unbinding the GPIO device, then calling any of the system calls
relevant to the GPIO character device's annonymous file descriptors:
ioctl(), read(), poll().

While I observed it with the GPIO simulator, it will also happen for any
of the GPIO devices that can be hot-unplugged - for instance any HID GPIO
expander (e.g. CP2112).

This affects both v1 and v2 uAPI.

This fixes it partially by checking if gdev->chip is not NULL but it
doesn't entirely remedy the situation as we still have a race condition
in which another thread can remove the device after the check.


Affected upstream versions: 4.8
Fixed upstream versions: 0, 5.10.163, 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: 6d79546622baab843172b52c3af035f83c1b21df
CVE-2022-50459: kernel: scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
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-01T00:00:00+00:00

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

scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()

Fix a NULL pointer crash that occurs when we are freeing the socket at the
same time we access it via sysfs.

The problem is that:

 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take
    the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()
    does a get on the "struct sock".

 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put
    on the "struct socket" and that does __sock_release() which sets the
    sock->ops to NULL.

 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then
    call kernel_getpeername() which accesses the NULL sock->ops.

Above we do a get on the "struct sock", but we needed a get on the "struct
socket". Originally, we just held the frwd_lock the entire time but in
commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while
calling getpeername()") we switched to refcount based because the network
layer changed and started taking a mutex in that path, so we could no
longer hold the frwd_lock.

Instead of trying to maintain multiple refcounts, this just has us use a
mutex for accessing the socket in the interface code paths.


Affected upstream versions: 5.8.14 < 5.9, 5.9
Fixed upstream versions: 0, 5.10.150, 5.15.75, 5.19.17, 5.9, 6.0.3, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 884a788f065578bb640382279a83d1df433b13e6
CVE-2022-50464: kernel: mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()
Component: kernel
Severity: Moderate
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
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-01T00:00:00+00:00

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

mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()

As comment of pci_get_device() says, it returns a pci_device with its
refcount increased. We need to call pci_dev_put() to decrease the
refcount. Save the return value of pci_get_device() and call
pci_dev_put() to decrease the refcount.


Affected upstream versions: 5.12
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: 8abc6579667129afd13ff2ccb0319ba3f46e6995
CVE-2022-50465: kernel: Linux kernel ext4: Information Disclosure via uninitialized memory leak in fast-commit journal
Component: kernel
Severity: Low
CWE: CWE-909 (Missing Initialization of Resource)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N)
Public date: 2025-10-01T00:00:00+00:00

A flaw was found in the Linux kernel. A local attacker could exploit an information disclosure vulnerability by not properly zeroing out unused space at the end of fast-commit journal blocks in the ext4 filesystem. This could lead to the leakage of uninitialized memory to disk, potentially allowing information disclosure.


Affected upstream versions: 5.10
Fixed upstream versions: 0, 5.10.163, 5.15.87, 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: b8b7922374b00a44137e5bcdd46ef86c8b065f27
CVE-2022-50467: kernel: scsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID
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-01T00:00:00+00:00

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

scsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID

An error case exit from lpfc_cmpl_ct_cmd_gft_id() results in a call to
lpfc_nlp_put() with a null pointer to a nodelist structure.

Changed lpfc_cmpl_ct_cmd_gft_id() to initialize nodelist pointer upon
entry.


Affected upstream versions: 5.14
Fixed upstream versions: 0, 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: 04e7cd8c85636a329d1a6e5a269a7c8b6f71c41c
CVE-2022-50468: kernel: platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()
Component: kernel
Severity: Moderate
CWE: CWE-252 (Unchecked Return Value)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:H)
Public date: 2025-10-01T00:00:00+00:00

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

platform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()

The following WARNING message was given when rmmod cros_usbpd_notify:

 Unexpected driver unregister!
 WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0
 Modules linked in: cros_usbpd_notify(-)
 CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24
 ...
 Call Trace:
  <TASK>
  cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]
  __x64_sys_delete_module+0x3c7/0x570
  ? __ia32_sys_delete_module+0x570/0x570
  ? lock_is_held_type+0xe3/0x140
  ? syscall_enter_from_user_mode+0x17/0x50
  ? rcu_read_lock_sched_held+0xa0/0xd0
  ? syscall_enter_from_user_mode+0x1c/0x50
  do_syscall_64+0x37/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
 RIP: 0033:0x7f333fe9b1b7

The reason is that the cros_usbpd_notify_init() does not check the return
value of platform_driver_register(), and the cros_usbpd_notify can
install successfully even if platform_driver_register() failed.

Fix by checking the return value of platform_driver_register() and
unregister cros_usbpd_notify_plat_driver when it failed.


Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.163, 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: 5c0cacdd354987f8f5348d16908716f154047890
CVE-2022-50470: kernel: xhci: Remove device endpoints from bandwidth list when freeing the device
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-04T00:00:00+00:00

A null pointer/list corruption flaw was found in the Linux kernel USB xHCI host controller code. When the xHCI host is dying or being removed, some device endpoints may remain on the software bandwidth list. Later cleanup deletes entries that were already freed, corrupting the list and crashing the kernel.
A local user could use this flaw to crash system, causing denial of service.

Statement: This vulnerability is limited to systems using software bandwidth checking, noted as affecting Intel Panther Point PCH (Ivy Bridge) xHC; other hosts perform bandwidth checks in hardware. The crash occurs when endpoints aren’t dropped cleanly as the controller is removed/dies, leaving them on the bandwidth list; subsequent free-path cleanup (xhci_mem_cleanup) attempts to delete already-freed endpoints, corrupting the list and triggering a kernel crash.

Affected upstream versions: 3.2
Fixed upstream versions: 0, 4.14.298, 4.19.264, 4.9.332, 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: 5e4ce28ad907aa54f13b21d5f1dc490525957b0c
CVE-2022-50472: kernel: IB/mad: Don't call to function that might sleep while in atomic context
Component: kernel
Severity: Low
CWE: CWE-474 (Use of Function with Inconsistent Implementations)
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:

IB/mad: Don't call to function that might sleep while in atomic context

Tracepoints are not allowed to sleep, as such the following splat is
generated due to call to ib_query_pkey() in atomic context.

WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220
CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-305.3.1.el8.x86_64 #1
 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014
 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core]
 RIP: 0010:rb_commit+0xc1/0x220
 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202
 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246
 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00
 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246
 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0
 Call Trace:
  ring_buffer_unlock_commit+0x1d/0xa0
  trace_buffer_unlock_commit_regs+0x3b/0x1b0
  trace_event_buffer_commit+0x67/0x1d0
  trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core]
  ib_mad_recv_done+0x48b/0xc10 [ib_core]
  ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core]
  __ib_process_cq+0x91/0x1c0 [ib_core]
  ib_cq_poll_work+0x26/0x80 [ib_core]
  process_one_work+0x1a7/0x360
  ? create_worker+0x1a0/0x1a0
  worker_thread+0x30/0x390
  ? create_worker+0x1a0/0x1a0
  kthread+0x116/0x130
  ? kthread_flush_work_fn+0x10/0x10
  ret_from_fork+0x35/0x40
 ---[ end trace 78ba8509d3830a16 ]---


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.258, 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: d45e6ccb8e98d8339631f32984d345a663e74ce2
CVE-2022-50473: kernel: cpufreq: Init completion before kobject_init_and_add()
Component: kernel
Severity: Low
CWE: CWE-909 (Missing Initialization of 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

An initialization order bug was found in the Linux kernel's cpufreq subsystem during policy allocation. A local user can trigger this issue when CPU frequency policy initialization fails after kobject registration but before completion initialization, causing the cleanup path to attempt to use an uninitialized completion variable. This results in a page fault and kernel crash, leading to denial of service.

Statement: The cpufreq_policy_alloc function creates CPU frequency policy objects and registers them with the sysfs kobject infrastructure. During this process, a completion variable is used for synchronization when the policy object is eventually released. The problem is timing: kobject_init_and_add can fail, triggering an error cleanup path that calls kobject_put. This leads to cpufreq_sysfs_release being invoked, which tries to complete on the completion variable—but that variable hasn't been initialized yet because init_completion is called after the kobject registration. Accessing an uninitialized completion causes the kernel to dereference invalid memory (specifically address 0xfffffffffffffff8), resulting in an immediate page fault and crash. This can happen during normal CPU frequency driver initialization when any of various failure conditions occur, such as memory allocation failures or sysfs registration conflicts.

Affected upstream versions: 5.1.6 < 5.2, 5.2
Fixed upstream versions: 0, 5.10.163, 5.15.87, 5.2, 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: 3cdd91a9163248935720927531066b74f57aa43b
CVE-2022-50475: kernel: RDMA/core: Make sure "ib_port" is valid when access sysfs node
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired 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 flaw was found in the Linux kernel RDMA core's sysfs handling. A local user with access to InfiniBand sysfs nodes can read sysfs attributes while an InfiniBand port is being removed, causing the kernel to dereference a NULL ib_port pointer when the port structure has been freed but sysfs access is still possible, which results in a NULL pointer dereference and denial of service through kernel crash.

Statement: The issue arises because sysfs attribute handlers fail to validate that the ib_port pointer is non-NULL before dereferencing it. When userspace accesses sysfs nodes under /sys/class/infiniband/ (such as port state, capabilities, or statistics), the kernel retrieves the associated port structure. During device removal or port state changes, the port structure can be freed while sysfs nodes still exist. If a sysfs read occurs during or after this removal, the code dereferences a NULL or freed ib_port pointer, causing a kernel crash. This can be triggered by simply reading sysfs attributes while removing or reconfiguring InfiniBand devices.

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: f981c697b2f9bd5dd2f060e47ff8b5e0a2cd0c06
CVE-2022-50479: kernel: drm/amd: fix potential 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-04T00:00:00+00:00

A memory leak was found in the Linux kernel's AMD display driver in the clock source initialization logic. When the initialization function encounters an error in its final return path, allocated memory for the clk_src structure is not freed before returning NULL. This results in leaked memory that accumulates with repeated initialization attempts, leading to resource exhaustion and denial of service.

Statement: The AMD display driver allocates memory for clock source structures during hardware initialization. In one particular error path—specifically, when the function reaches its last return NULL statement—the code fails to free the previously allocated clk_src memory. While this appears to be a straightforward oversight, it can become significant during scenarios where initialization repeatedly fails, such as during hardware probing, driver reload cycles, or error recovery attempts. Each failed initialization leaves behind orphaned memory that cannot be reclaimed. The leak is specific to AMD display hardware and manifests during driver initialization rather than during normal runtime operation.

Affected upstream versions: 5.11
Fixed upstream versions: 0, 6.0.3, 6.1
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a6e6ab9caeac96b277a3fe7da1dfa8f69a591759
CVE-2022-50482: kernel: iommu/vt-d: Clean up si_domain in the init_dmars() error path
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-04T00:00:00+00:00

A memory leak flaw was found in the Linux kernel's Intel VT-d IOMMU driver in the initialization error path. A local user can trigger this issue when the init_dmars function fails during IOMMU setup, causing the si_domain memory to remain allocated without being freed. This results in a permanent memory leak leading to resource exhaustion and denial of service.

Statement: The init_dmars function performs IOMMU initialization and allocates the si_domain (shared identity domain) for devices that can bypass IOMMU translation. When initialization fails partway through, the error path returns without cleaning up the si_domain allocation. Since this is a boot-time initialization function, the leak occurs once per failed initialization attempt. While the leak was originally detected through kmem_cache errors, even after mempool removal the underlying memory leak persists. The issue requires conditions that cause IOMMU initialization to fail, which can occur due to hardware issues, misconfigurations, or resource constraints during boot.

Affected upstream versions: 4.2
Fixed upstream versions: 0, 4.14.298, 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: 749bea542b67513e99240dc58bbfc099e842d508
CVE-2022-50484: kernel: ALSA: usb-audio: Fix potential memory leaks
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 memory leak was found in the Linux kernel's USB audio driver in the synchronization endpoint URB allocation path. When memory allocation fails partway through allocating URBs for a sync endpoint, the error handling code fails to release the partially allocated URBs because the endpoint's URB counter hasn't been updated yet. This leaves allocated URBs orphaned in memory, leading to resource exhaustion and denial of service with repeated failures.

Statement: USB audio devices often use isochronous endpoints for audio streaming, with separate synchronization endpoints for clock recovery. During initialization, the driver allocates multiple URBs (USB Request Blocks) for these endpoints. The allocation happens in a loop: create URB, allocate buffer, repeat. The ep->nurbs field tracks how many URBs have been successfully allocated. Here's the problem: ep->nurbs is only set after the entire loop completes successfully. If allocation fails midway—say, the driver successfully allocates 5 URBs but fails on the 6th due to -ENOMEM—the error handler is supposed to clean up. It loops from 0 to ep->nurbs, freeing each URB. But since ep->nurbs is still zero (it was never updated), the loop doesn't execute at all. The 5 successfully allocated URBs are simply abandoned. Each time USB audio initialization fails under memory pressure, more URBs leak. The fix is simple: set ep->nurbs before starting the loop, so the cleanup knows how far to iterate.

Affected upstream versions: 3.5
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: 0604e5e5537af099ea2f6dfd892afe5c92db8a80
CVE-2022-50485: kernel: ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode
Component: kernel
Severity: Moderate
CWE: CWE-654 (Reliance on a Single Factor in a Security Decision)
CVSS v3: 5.7 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:H/A:H)
Public date: 2025-10-04T00:00:00+00:00

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

ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inode

There are many places that will get unhappy (and crash) when ext4_iget()
returns a bad inode. However, if iget the boot loader inode, allows a bad
inode to be returned, because the inode may not be initialized. This
mechanism can be used to bypass some checks and cause panic. To solve this
problem, we add a special iget flag EXT4_IGET_BAD. Only with this flag
we'd be returning bad inode from ext4_iget(), otherwise we always return
the error code if the inode is bad inode.(suggested by Jan Kara)


Affected upstream versions: 3.10
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: 2142dfa1de61e25b83198af0308ec7689cca25d3