huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2023-53264: kernel: clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe
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-09-16T00:00:00+00:00

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

clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe

Use devm_of_iomap() instead of of_iomap() to automatically
handle the unused ioremap region. If any error occurs, regions allocated by
kzalloc() will leak, but using devm_kzalloc() instead will automatically
free the memory using devm_kfree().

Also, fix error handling of hws by adding unregister_hws label, which
unregisters remaining hws when iomap failed.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 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: 1839032251a66f2ae5a043c495532830a55d28c4
CVE-2023-53266: kernel: arm64: acpi: Fix possible memory leak of ffh_ctxt
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-09-16T00:00:00+00:00

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

arm64: acpi: Fix possible memory leak of ffh_ctxt

Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version
and conduit checks fail and -EOPNOTSUPP is returned without freeing the
allocated memory.

Fix the same by moving the allocation after the SMCCC version and
conduit checks.


Affected upstream versions: 6.2
Fixed upstream versions: 0, 6.2.3, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7521da2eb42d65f89f511b7912d3757cf3d9168a
CVE-2023-53270: kernel: ext4: fix i_disksize exceeding i_size problem in paritally written case
Component: kernel
Severity: Moderate
CWE: CWE-130 (Improper Handling of Length Parameter Inconsistency)
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-09-16T00:00:00+00:00

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

ext4: fix i_disksize exceeding i_size problem in paritally written case

It is possible for i_disksize can exceed i_size, triggering a warning.

generic_perform_write
 copied = iov_iter_copy_from_user_atomic(len) // copied < len
 ext4_da_write_end
 | ext4_update_i_disksize
 |  new_i_size = pos + copied;
 |  WRITE_ONCE(EXT4_I(inode)->i_disksize, newsize) // update i_disksize
 | generic_write_end
 |  copied = block_write_end(copied, len) // copied = 0
 |   if (unlikely(copied < len))
 |    if (!PageUptodate(page))
 |     copied = 0;
 |  if (pos + copied > inode->i_size) // return false
 if (unlikely(copied == 0))
  goto again;
 if (unlikely(iov_iter_fault_in_readable(i, bytes))) {
  status = -EFAULT;
  break;
 }

We get i_disksize greater than i_size here, which could trigger WARNING
check 'i_size_read(inode) < EXT4_I(inode)->i_disksize' while doing dio:

ext4_dio_write_iter
 iomap_dio_rw
  __iomap_dio_rw // return err, length is not aligned to 512
 ext4_handle_inode_extension
  WARN_ON_ONCE(i_size_read(inode) < EXT4_I(inode)->i_disksize) // Oops

 WARNING: CPU: 2 PID: 2609 at fs/ext4/file.c:319
 CPU: 2 PID: 2609 Comm: aa Not tainted 6.3.0-rc2
 RIP: 0010:ext4_file_write_iter+0xbc7
 Call Trace:
  vfs_write+0x3b1
  ksys_write+0x77
  do_syscall_64+0x39

Fix it by updating 'copied' value before updating i_disksize just like
ext4_write_inline_data_end() does.

A reproducer can be found in the buganizer link below.


Affected upstream versions: 2.6.27
Fixed upstream versions: 0, 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: 18eb23891aeae3229baf8c7c23b76be3364e1967
CVE-2023-53273: kernel: Drivers: vmbus: Check for channel allocation before looking up relids
Component: kernel
Severity: Moderate
CWE: CWE-476 (NULL Pointer Dereference)
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-09-16T00:00:00+00:00

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

Drivers: vmbus: Check for channel allocation before looking up relids

relid2channel() assumes vmbus channel array to be allocated when called.
However, in cases such as kdump/kexec, not all relids will be reset by the host.
When the second kernel boots and if the guest receives a vmbus interrupt during
vmbus driver initialization before vmbus_connect() is called, before it finishes,
or if it fails, the vmbus interrupt service routine is called which in turn calls
relid2channel() and can cause a null pointer dereference.

Print a warning and error out in relid2channel() for a channel id that's invalid
in the second kernel.


Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.178, 5.15.107, 6.1.24, 6.2.11, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 176c6b4889195fbe7016d9401175b48c5c9edf68
CVE-2023-53275: kernel: ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()
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-09-16T00:00:00+00:00

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

ALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()

The variable codec->regmap is often protected by the lock
codec->regmap_lock when is accessed. However, it is accessed without
holding the lock when is accessed in snd_hdac_regmap_sync():

  if (codec->regmap)

In my opinion, this may be a harmful race, because if codec->regmap is
set to NULL right after the condition is checked, a null-pointer
dereference can occur in the called function regcache_sync():

  map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c

To fix this possible null-pointer dereference caused by data race, the
mutex_lock coverage is extended to protect the if statement as well as the
function call to regcache_sync().

[ Note: the lack of the regmap_lock itself is harmless for the current
  codec driver implementations, as snd_hdac_regmap_sync() is only for
  PM runtime resume that is prohibited during the codec probe.
  But the change makes the whole code more consistent, so it's merged
  as is -- tiwai ]


Affected upstream versions: 5.4.43 < 5.4.255, 5.6
Fixed upstream versions: 0, 5.10.192, 5.15.128, 5.4.255, 6.1.47, 6.4.12, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 109f0aaa0b8838a88af9125b79579023539300a7
CVE-2023-53280: kernel: scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue
Component: kernel
Severity: Moderate
CWE: CWE-824 (Access of Uninitialized Pointer)
CVSS v3: 6.4 (CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-09-16T00:00:00+00:00

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

scsi: qla2xxx: Remove unused nvme_ls_waitq wait queue

System crash when qla2x00_start_sp(sp) returns error code EGAIN and wake_up
gets called for uninitialized wait queue sp->nvme_ls_waitq.

    qla2xxx [0000:37:00.1]-2121:5: Returning existing qpair of ffff8ae2c0513400 for idx=0
    qla2xxx [0000:37:00.1]-700e:5: qla2x00_start_sp failed = 11
    BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
    PGD 0 P4D 0
    Oops: 0000 [#1] SMP NOPTI
    Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
    Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
    RIP: 0010:__wake_up_common+0x4c/0x190
    RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
    RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
    RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
    R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
    R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
    FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    PKRU: 55555554
    Call Trace:
     __wake_up_common_lock+0x7c/0xc0
     qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
     ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
     ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
     ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]

Remove unused nvme_ls_waitq wait queue. nvme_ls_waitq logic was removed
previously in the commits tagged Fixed: below.


Affected upstream versions: 4.14
Fixed upstream versions: 0, 5.10.188, 5.15.121, 5.4.251, 6.1.40, 6.4.5, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b7084ebf4f54d46fed5153112d685f4137334175
CVE-2023-53285: kernel: ext4: add bounds checking in get_max_inline_xattr_value_size()
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 6.3 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-09-16T00:00:00+00:00

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

ext4: add bounds checking in get_max_inline_xattr_value_size()

Normally the extended attributes in the inode body would have been
checked when the inode is first opened, but if someone is writing to
the block device while the file system is mounted, it's possible for
the inode table to get corrupted.  Add bounds checking to avoid
reading beyond the end of allocated memory if this happens.


Affected upstream versions: 3.8
Fixed upstream versions: 0, 4.14.315, 4.19.283, 5.10.180, 5.15.112, 5.4.243, 6.1.29, 6.2.16, 6.3.3, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5a229d21b98d132673096710e8281ef522dab1d1
CVE-2023-53287: kernel: Linux kernel: Denial of Service in the cdns3 USB driver due to improper spin lock handling
Component: kernel
Severity: Low
CWE: CWE-663 (Use of a Non-reentrant Function in a Concurrent 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-09-16T00:00:00+00:00

A flaw was found in the Linux kernel's cdns3 USB driver. During the device resume process, the pm_runtime_set_active function was incorrectly called from within a spin lock, which is an atomic operation. This improper handling can lead to a system crash, resulting in a Denial of Service (DoS). A local attacker could potentially trigger this condition.


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.15.133, 6.1.55, 6.5.5, 6.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c861a61be6d30538ebcf7fcab1d43f244e298840
CVE-2023-53288: kernel: drm/client: Fix memory leak in drm_client_modeset_probe
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-09-16T00:00:00+00:00

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

drm/client: Fix memory leak in drm_client_modeset_probe

When a new mode is set to modeset->mode, the previous mode should be freed.
This fixes the following kmemleak report:

drm_mode_duplicate+0x45/0x220 [drm]
drm_client_modeset_probe+0x944/0xf50 [drm]
__drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]
drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]
drm_client_register+0x169/0x240 [drm]
ast_pci_probe+0x142/0x190 [ast]
local_pci_probe+0xdc/0x180
work_for_cpu_fn+0x4e/0xa0
process_one_work+0x8b7/0x1540
worker_thread+0x70a/0xed0
kthread+0x29f/0x340
ret_from_fork+0x1f/0x30


Affected upstream versions: 4.8.7 < 4.9, 4.9
Fixed upstream versions: 0, 4.9, 5.10.188, 5.15.123, 5.4.251, 6.1.42, 6.4.7, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5d580017bdb9b3e930b6009e467e5e1589f8ca8a
CVE-2023-53290: kernel: Linux kernel: Denial of Service due to file descriptor leak in BPF sample code
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-09-16T00:00:00+00:00

A flaw was found in the Linux kernel. This vulnerability, a file descriptor leak, occurs in the samples/bpf component when the fout file pointer is opened but not properly closed in the hbm's run_bpf_prog function. A local attacker could exploit this by repeatedly triggering the flaw, leading to resource exhaustion and a Denial of Service (DoS) on the system.


Affected upstream versions: 5.1
Fixed upstream versions: 0, 5.10.181, 5.15.113, 5.4.244, 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: a7ec2f424f6edad34651137783a0a59eca9aa37e
CVE-2023-53296: kernel: sctp: check send stream number after wait_for_sndbuf
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-09-16T00:00:00+00:00

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

sctp: check send stream number after wait_for_sndbuf

This patch fixes a corner case where the asoc out stream count may change
after wait_for_sndbuf.

When the main thread in the client starts a connection, if its out stream
count is set to N while the in stream count in the server is set to N - 2,
another thread in the client keeps sending the msgs with stream number
N - 1, and waits for sndbuf before processing INIT_ACK.

However, after processing INIT_ACK, the out stream count in the client is
shrunk to N - 2, the same to the in stream count in the server. The crash
occurs when the thread waiting for sndbuf is awake and sends the msg in a
non-existing stream(N - 1), the call trace is as below:

  KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
  Call Trace:
   <TASK>
   sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]
   sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]
   sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]
   sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170
   sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163
   sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868
   sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026
   inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825
   sock_sendmsg_nosec net/socket.c:722 [inline]
   sock_sendmsg+0xde/0x190 net/socket.c:745

The fix is to add an unlikely check for the send stream number after the
thread wakes up from the wait_for_sndbuf.


Affected upstream versions: 4.15
Fixed upstream versions: 0, 4.19.281, 5.10.178, 5.15.107, 5.4.241, 6.1.24, 6.2.11, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 9346a1a21142357972a6f466ba6275ddc54b04ac
CVE-2023-53297: kernel: Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp
Component: kernel
Severity: Moderate
CWE: CWE-832 (Unlock of a Resource that is not Locked)
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-09-16T00:00:00+00:00

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

Bluetooth: L2CAP: fix "bad unlock balance" in l2cap_disconnect_rsp

conn->chan_lock isn't acquired before l2cap_get_chan_by_scid,
if l2cap_get_chan_by_scid returns NULL, then 'bad unlock balance'
is triggered.


Affected upstream versions: 4.14.313 < 4.14.316, 4.19.281 < 4.19.284, 5.4.241 < 5.4.244, 5.10.178 < 5.10.181, 5.15.108 < 5.15.113, 6.1.25 < 6.1.30, 6.2.12 < 6.3, 6.3
Fixed upstream versions: 0, 4.14.316, 4.19.284, 5.10.181, 5.15.113, 5.4.244, 6.1.30, 6.3, 6.3.4, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 5f352a56f0e607e6ff539cbf12156bfd8af232be
CVE-2023-53299: kernel: md/raid10: fix leak of 'r10bio->remaining' for recovery
Component: kernel
Severity: Moderate
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
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-09-16T00:00:00+00:00

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

md/raid10: fix leak of 'r10bio->remaining' for recovery

raid10_sync_request() will add 'r10bio->remaining' for both rdev and
replacement rdev. However, if the read io fails, recovery_request_write()
returns without issuing the write io, in this case, end_sync_request()
is only called once and 'remaining' is leaked, cause an io hang.

Fix the problem by decreasing 'remaining' according to if 'bio' and
'repl_bio' is valid.

Statement: RAID10 recovery could leak the r10bio->remaining counter on read failure, preventing completion and causing an I/O hang. The fix decrements the counter only for actually issued bios, avoiding the stall.
This is a reliability bug, not remotely triggerable: it requires a RAID10 in recovery and device read errors, typically under administrative control. Impact is limited to availability (local I/O DoS).

Affected upstream versions: 3.3
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: cb827ed2bb34480dc102146d3a1f89fdbcafc028
CVE-2023-53304: kernel: Linux kernel: Denial of Service in netfilter due to improper garbage collection
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-09-16T00:00:00+00:00

A flaw was found in the Linux kernel's netfilter component, specifically within the nft_set_rbtree module. A local user with low privileges could exploit an issue where the garbage collection mechanism fails to properly release memory during interval expiration walks. This can lead to a memory leak, potentially causing a Denial of Service (DoS) on the system.


Affected upstream versions: 5.10.166 < 5.10.190, 5.15.91 < 5.15.124, 6.1.9 < 6.1.43, 6.2
Fixed upstream versions: 0, 5.10.190, 5.15.124, 6.1.43, 6.4.8, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8284a79136c384059e85e278da2210b809730287
CVE-2023-53305: kernel: Bluetooth: L2CAP: Fix use-after-free
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
CVSS v3: 7.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-09-16T00:00:00+00:00

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

Bluetooth: L2CAP: Fix use-after-free

Fix potential use-after-free in l2cap_le_command_rej.

Statement: This L2CAP issue is adjacency-only (Bluetooth LE): an attacker must be within radio range and craft malicious LE frames. Impact is primarily kernel crash / DoS.
It could trigger a use-after-free condition when processing LE command rejection.
In practice an attacker must either establish a BLE connection or rely on the device accepting unauthenticated L2CAP traffic. If the device enforces pairing/authentication for L2CAP operations, exploitation from an unauthenticated remote actor is unlikely.
Fixed in Red Hat Enterprise Linux 9 starting from 9.4.

Affected upstream versions: 3.14
Fixed upstream versions: 0, 4.14.324, 4.19.293, 5.10.192, 5.15.128, 5.4.255, 6.1.47, 6.4.12, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e76bab1b7afa580cd76362540fc37551ada4359b
CVE-2023-53309: kernel: Linux kernel: Denial of Service via integer overflow in radeon_cs_parser_init
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-09-16T00:00:00+00:00

A flaw was found in the Linux kernel's drm/radeon component. A local attacker with low privileges could exploit an integer overflow vulnerability in the radeon_cs_parser_init function. This flaw causes a size variable to become zero, leading to the referencing of uninitialized memory. This can result in a system crash, causing a denial of service (DoS).


Affected upstream versions: 3.13
Fixed upstream versions: 0, 4.14.324, 4.19.293, 5.10.192, 5.15.123, 5.4.255, 6.1.42, 6.4.7, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d05ba46134d07e889de7d23cf8503574a22ede09
CVE-2023-53317: kernel: ext4: fix WARNING in mb_find_extent
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-09-16T00:00:00+00:00

A vulnerability was found in the ext4 filesystem driver in the Linux kernel. This flaw occurs when the system processes a maliciously crafted or corrupted ext4 filesystem image, as the driver fails to properly validate its structural data. A local user with the ability to mount such an image could use this flaw to cause a system crash, resulting in a denial of service. This vulnerability could also lead to silent corruption of data on the affected filesystem.

Statement: This vulnerability will only result in a Denial of Service when the panic_on_warn flag is enabled, which is not the default configuration for Red hat Linux installations.

Red Hat Product Security team has rated this vulnerability as having a Moderate severity due to the fact an attacker needs to have privileges to mount the filesystem, additionally the complexity of corrupting the block bitmap can be considered high and the attacker has no full control on how the data will be corrupted in a event of a successful attack.

Affected upstream versions: 2.6.25
Fixed upstream versions: 0, 4.19.283, 5.10.180, 5.15.112, 5.4.243, 6.1.29, 6.2.16, 6.3.3, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 775b00ba23f6f916fe2ac60c5ff7fd0fe4f28d0d
CVE-2023-53320: kernel: scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()
Component: kernel
Severity: Moderate
CWE: CWE-131 (Incorrect Calculation of Buffer Size)
CVSS v3: 6 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-09-16T00:00:00+00:00

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

scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info()

The function mpi3mr_get_all_tgt_info() has four issues:

1) It calculates valid entry length in alltgt_info assuming the header part
   of the struct mpi3mr_device_map_info would equal to sizeof(u32).  The
   correct size is sizeof(u64).

2) When it calculates the valid entry length kern_entrylen, it excludes one
   entry by subtracting 1 from num_devices.

3) It copies num_device by calling memcpy(). Substitution is enough.

4) It does not specify the calculated length to sg_copy_from_buffer().
   Instead, it specifies the payload length which is larger than the
   alltgt_info size. It causes "BUG: KASAN: slab-out-of-bounds".

Fix the issues by using the correct header size, removing the subtraction
from num_devices, replacing the memcpy() with substitution and specifying
the correct length to sg_copy_from_buffer().


Affected upstream versions: 5.19
Fixed upstream versions: 0, 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: 8ba997b22f2cd5d29aad8c39f6201f7608ed0c04