huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2023-53125: kernel: net: usb: smsc75xx: Limit packet length to skb->len
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
Public date: 2025-05-02T00:00:00+00:00

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

net: usb: smsc75xx: Limit packet length to skb->len

Packet length retrieved from skb data may be larger than
the actual socket buffer length (up to 9026 bytes). In such
case the cloned skb passed up the network stack will leak
kernel memory contents.

Statement: The vulnerability in SMSC LAN75XX based USB 2.0 gigabit ethernet devices driver arises because the driver fails to properly validate packet length fields when receiving network frames. Specifically, the code used size values that could exceed the actual skb->len, leading to a situation where kernel memory beyond the buffer is copied into the outgoing skb. If the driver is active, a remote attacker on the same network can send oversized Ethernet frames to trigger this bug, resulting in leakage of uninitialized kernel memory (CIA: HNN, Confidentiality: High).

Affected upstream versions: 2.6.34
Fixed upstream versions: 0, 4.14.311, 4.19.279, 5.10.176, 5.15.104, 5.4.238, 6.1.21, 6.2.8, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4a4de0a68b18485c68ab4f0cfa665b1633c6d277
CVE-2023-53126: kernel: scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove()
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-05-02T00:00:00+00:00

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

scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove()

Free mrioc->sas_hba.phy at .remove.


Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.1.21, 6.2.8, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 480aae2f30637b5140e9c7a9b10298e538df2b5e
CVE-2023-53132: kernel: scsi: mpi3mr: Fix mpi3mr_hba_port memory leak in mpi3mr_remove()
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory 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-05-02T00:00:00+00:00

A flaw was found in the mpi3mr module in the Linux kernel. The missing release of memory allocated for mpi3mr_hba_port will cause a memory leak, potentially impacting system stability and resulting in a denial of service.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.9 and 9.3 via RHSA-2023:7077 [1] and RHSA-2023:6583 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2023:7077

[2]. https://access.redhat.com/errata/RHSA-2023:6583

Affected upstream versions: 6.1
Fixed upstream versions: 0, 6.1.21, 6.2.8, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f28bdab9e208792212c52b0c232a13bba84cf048
CVE-2023-53134: kernel: bnxt_en: Avoid order-5 memory allocation for TPA 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-05-02T00:00:00+00:00

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

bnxt_en: Avoid order-5 memory allocation for TPA data

The driver needs to keep track of all the possible concurrent TPA (GRO/LRO)
completions on the aggregation ring.  On P5 chips, the maximum number
of concurrent TPA is 256 and the amount of memory we allocate is order-5
on systems using 4K pages.  Memory allocation failure has been reported:

NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1
CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1
Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022
Call Trace:
 dump_stack+0x57/0x6e
 warn_alloc.cold.120+0x7b/0xdd
 ? _cond_resched+0x15/0x30
 ? __alloc_pages_direct_compact+0x15f/0x170
 __alloc_pages_slowpath.constprop.108+0xc58/0xc70
 __alloc_pages_nodemask+0x2d0/0x300
 kmalloc_order+0x24/0xe0
 kmalloc_order_trace+0x19/0x80
 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en]
 ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en]
 __bnxt_open_nic+0x12e/0x780 [bnxt_en]
 bnxt_open+0x10b/0x240 [bnxt_en]
 __dev_open+0xe9/0x180
 __dev_change_flags+0x1af/0x220
 dev_change_flags+0x21/0x60
 do_setlink+0x35c/0x1100

Instead of allocating this big chunk of memory and dividing it up for the
concurrent TPA instances, allocate each small chunk separately for each
TPA instance.  This will reduce it to order-0 allocations.


Affected upstream versions: 5.4
Fixed upstream versions: 0, 5.10.175, 5.15.103, 5.4.237, 6.1.20, 6.2.7, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 16f3aae1aa2dd89bc8d073a67f190af580386ae9
CVE-2023-53140: kernel: scsi: core: Remove the /proc/scsi/${proc_name} directory earlier
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-05-02T00:00:00+00:00

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

scsi: core: Remove the /proc/scsi/${proc_name} directory earlier

Remove the /proc/scsi/${proc_name} directory earlier to fix a race
condition between unloading and reloading kernel modules. This fixes a bug
introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in
the SCSI core").

Fix the following kernel warning:

proc_dir_entry 'scsi/scsi_debug' already registered
WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0
Call Trace:
 proc_mkdir+0xb5/0xe0
 scsi_proc_hostdir_add+0xb5/0x170
 scsi_host_alloc+0x683/0x6c0
 sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]
 really_probe+0x159/0x540
 __driver_probe_device+0xdc/0x230
 driver_probe_device+0x4f/0x120
 __device_attach_driver+0xef/0x180
 bus_for_each_drv+0xe5/0x130
 __device_attach+0x127/0x290
 device_initial_probe+0x17/0x20
 bus_probe_device+0x110/0x130
 device_add+0x673/0xc80
 device_register+0x1e/0x30
 sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]
 scsi_debug_init+0x64f/0x1000 [scsi_debug]
 do_one_initcall+0xd7/0x470
 do_init_module+0xe7/0x330
 load_module+0x122a/0x12c0
 __do_sys_finit_module+0x124/0x1a0
 __x64_sys_finit_module+0x46/0x50
 do_syscall_64+0x38/0x80
 entry_SYSCALL_64_after_hwframe+0x46/0xb0


Affected upstream versions: 2.6.30
Fixed upstream versions: 0, 4.19.278, 5.10.175, 5.15.103, 5.4.237, 6.1.20, 6.2.7, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 13daafe1e209b03e9bda16ff2bd2b2da145a139b
CVE-2023-53148: kernel: igb: Fix igb_down hung on surprise removal
Component: kernel
Severity: Moderate
CWE: CWE-1341 (Multiple Releases of Same Resource or Handle)
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-15T00:00:00+00:00

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

igb: Fix igb_down hung on surprise removal

In a setup where a Thunderbolt hub connects to Ethernet and a display
through USB Type-C, users may experience a hung task timeout when they
remove the cable between the PC and the Thunderbolt hub.
This is because the igb_down function is called multiple times when
the Thunderbolt hub is unplugged. For example, the igb_io_error_detected
triggers the first call, and the igb_remove triggers the second call.
The second call to igb_down will block at napi_synchronize.
Here's the call trace:
    __schedule+0x3b0/0xddb
    ? __mod_timer+0x164/0x5d3
    schedule+0x44/0xa8
    schedule_timeout+0xb2/0x2a4
    ? run_local_timers+0x4e/0x4e
    msleep+0x31/0x38
    igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4]
    __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4]
    igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4]
    __dev_close_many+0x95/0xec
    dev_close_many+0x6e/0x103
    unregister_netdevice_many+0x105/0x5b1
    unregister_netdevice_queue+0xc2/0x10d
    unregister_netdev+0x1c/0x23
    igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4]
    pci_device_remove+0x3f/0x9c
    device_release_driver_internal+0xfe/0x1b4
    pci_stop_bus_device+0x5b/0x7f
    pci_stop_bus_device+0x30/0x7f
    pci_stop_bus_device+0x30/0x7f
    pci_stop_and_remove_bus_device+0x12/0x19
    pciehp_unconfigure_device+0x76/0xe9
    pciehp_disable_slot+0x6e/0x131
    pciehp_handle_presence_or_link_change+0x7a/0x3f7
    pciehp_ist+0xbe/0x194
    irq_thread_fn+0x22/0x4d
    ? irq_thread+0x1fd/0x1fd
    irq_thread+0x17b/0x1fd
    ? irq_forced_thread_fn+0x5f/0x5f
    kthread+0x142/0x153
    ? __irq_get_irqchip_state+0x46/0x46
    ? kthread_associate_blkcg+0x71/0x71
    ret_from_fork+0x1f/0x30

In this case, igb_io_error_detected detaches the network interface
and requests a PCIE slot reset, however, the PCIE reset callback is
not being invoked and thus the Ethernet connection breaks down.
As the PCIE error in this case is a non-fatal one, requesting a
slot reset can be avoided.
This patch fixes the task hung issue and preserves Ethernet
connection by ignoring non-fatal PCIE errors.


Affected upstream versions: 2.6.25
Fixed upstream versions: 0, 4.14.322, 4.19.291, 5.10.188, 5.15.150, 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: c2312e1d12b1c3ee4100c173131b102e2aed4d04
CVE-2023-53149: kernel: ext4: avoid deadlock in fs reclaim with page writeback
Component: kernel
Severity: Moderate
CWE: CWE-833 (Deadlock)
CVSS v3: 5.8 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-09-15T00:00:00+00:00

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

ext4: avoid deadlock in fs reclaim with page writeback

Ext4 has a filesystem wide lock protecting ext4_writepages() calls to
avoid races with switching of journalled data flag or inode format. This
lock can however cause a deadlock like:

CPU0                            CPU1

ext4_writepages()
  percpu_down_read(sbi->s_writepages_rwsem);
                                ext4_change_inode_journal_flag()
                                  percpu_down_write(sbi->s_writepages_rwsem);
                                    - blocks, all readers block from now on
  ext4_do_writepages()
    ext4_init_io_end()
      kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)
        fs_reclaim frees dentry...
          dentry_unlink_inode()
            iput() - last ref =>
              iput_final() - inode dirty =>
                write_inode_now()...
                  ext4_writepages() tries to acquire sbi->s_writepages_rwsem
                    and blocks forever

Make sure we cannot recurse into filesystem reclaim from writeback code
to avoid the deadlock.


Affected upstream versions: 4.7
Fixed upstream versions: 0, 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: 2ec97dc90df40c50e509809dc9a198638a7e18b6
CVE-2023-53150: kernel: scsi: qla2xxx: Pointer may be dereferenced
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-15T00:00:00+00:00

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

scsi: qla2xxx: Pointer may be dereferenced

Klocwork tool reported pointer 'rport' returned from call to function
fc_bsg_to_rport() may be NULL and will be dereferenced.

Add a fix to validate rport before dereferencing.


Affected upstream versions: 3.1
Fixed upstream versions: 0, 4.14.322, 4.19.291, 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: 005961bd8f066fe931104f67c34ebfcc7f240099
CVE-2023-53151: kernel: Linux kernel: md/raid10 soft lockup due to unlimited plugged bio
Component: kernel
Severity: Low
CWE: CWE-770 (Allocation of Resources Without Limits or Throttling)
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-15T00:00:00+00:00

A flaw was found in the Linux kernel's Multiple Device (MD) driver, specifically within the RAID10 implementation. This vulnerability allows a local user to trigger a soft lockup, leading to a Denial of Service (DoS). The issue arises because the md/raid10 component lacks a limit on plugged bio (block input/output) requests during write flushing, causing the CPU to become unresponsive under heavy write operations.


Affected upstream versions: 2.6.16
Fixed upstream versions: 0, 4.14.322, 4.19.291, 5.10.188, 5.15.150, 5.4.251, 6.1.83, 6.4.7, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f45b2fa7678ab385299de345f7e85d05caea386b
CVE-2023-53152: kernel: drm/amdgpu: fix calltrace warning in amddrm_buddy_fini
Component: kernel
Severity: Moderate
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
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-09-15T00:00:00+00:00

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

drm/amdgpu: fix calltrace warning in amddrm_buddy_fini

The following call trace is observed when removing the amdgpu driver, which
is caused by that BOs allocated for psp are not freed until removing.

[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]
[61811.450577] Call Trace:
[61811.450577]  <TASK>
[61811.450579]  amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]
[61811.450728]  amdgpu_ttm_fini+0x207/0x290 [amdgpu]
[61811.450870]  amdgpu_bo_fini+0x27/0xa0 [amdgpu]
[61811.451012]  gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]
[61811.451166]  amdgpu_device_fini_sw+0x117/0x520 [amdgpu]
[61811.451306]  amdgpu_driver_release_kms+0x16/0x30 [amdgpu]
[61811.451447]  devm_drm_dev_init_release+0x4d/0x80 [drm]
[61811.451466]  devm_action_release+0x15/0x20
[61811.451469]  release_nodes+0x40/0xb0
[61811.451471]  devres_release_all+0x9b/0xd0
[61811.451473]  __device_release_driver+0x1bb/0x2a0
[61811.451476]  driver_detach+0xf3/0x140
[61811.451479]  bus_remove_driver+0x6c/0xf0
[61811.451481]  driver_unregister+0x31/0x60
[61811.451483]  pci_unregister_driver+0x40/0x90
[61811.451486]  amdgpu_exit+0x15/0x447 [amdgpu]

For smu v13_0_2, if the GPU supports xgmi, refer to

commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),

it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,
which makes all devices in hive list have hw reset but no resume except the
basic ip blocks, then other ip blocks will not call .hw_fini according to
ip_block.status.hw.

Since psp_free_shared_bufs just includes some software operations, so move
it to psp_sw_fini.


Affected upstream versions: 4.12
Fixed upstream versions: 0, 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: ab6f446c220db0c131f2071846afd835799be0fb
CVE-2023-53164: kernel: irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_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-15T00:00:00+00:00

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

irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probe

of_irq_find_parent() returns a node pointer with refcount incremented,
We should use of_node_put() on it when not needed anymore.
Add missing of_node_put() to avoid refcount leak.


Affected upstream versions: 5.2
Fixed upstream versions: 0, 5.10.173, 5.15.99, 5.4.235, 6.1.16, 6.2.3, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 07fceab32096c1290b491f2fcaace03f78e2db37
CVE-2023-53173: kernel: tty: pcn_uart: fix memory leak with using debugfs_lookup()
Component: kernel
Severity: Moderate
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-09-15T00:00:00+00:00

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

tty: pcn_uart: fix memory leak with using debugfs_lookup()

When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time.  To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.15.100, 6.1.18, 6.2.5, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: cf042964c2fa72950bbbf25b2cdd732b873e89db
CVE-2023-53176: kernel: serial: 8250: Reinit port->pm on port specific driver unbind
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-15T00:00:00+00:00

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

serial: 8250: Reinit port->pm on port specific driver unbind

When we unbind a serial port hardware specific 8250 driver, the generic
serial8250 driver takes over the port. After that we see an oops about 10
seconds later. This can produce the following at least on some TI SoCs:

Unhandled fault: imprecise external abort (0x1406)
Internal error: : 1406 [#1] SMP ARM

Turns out that we may still have the serial port hardware specific driver
port->pm in use, and serial8250_pm() tries to call it after the port
specific driver is gone:

serial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]
uart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]
uart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c
__tty_hangup.part.0 from disassociate_ctty+0x154/0x20c
disassociate_ctty from do_exit+0x744/0xaac
do_exit from do_group_exit+0x40/0x8c
do_group_exit from __wake_up_parent+0x0/0x1c

Let's fix the issue by calling serial8250_set_defaults() in
serial8250_unregister_port(). This will set the port back to using
the serial8250 default functions, and sets the port->pm to point to
serial8250_pm.

Statement: This vulnerability is rated Moderate for Red Hat Enterprise Linux. A privileged local attacker (ex. with `CAP_SYS_ADMIN` privileges) could cause a denial of service by unbinding a serial port hardware-specific 8250 driver, leading to a kernel oops.

Affected upstream versions: 2.6.37
Fixed upstream versions: 0, 4.14.316, 4.19.284, 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: 490bf37eaabb0a857ed1ae8e75d8854e41662f1c
CVE-2023-53178: kernel: mm: fix zswap writeback race condition
Component: kernel
Severity: Moderate
CWE: CWE-367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-09-15T00:00:00+00:00

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

mm: fix zswap writeback race condition

The zswap writeback mechanism can cause a race condition resulting in
memory corruption, where a swapped out page gets swapped in with data that
was written to a different page.

The race unfolds like this:
1. a page with data A and swap offset X is stored in zswap
2. page A is removed off the LRU by zpool driver for writeback in
   zswap-shrink work, data for A is mapped by zpool driver
3. user space program faults and invalidates page entry A, offset X is
   considered free
4. kswapd stores page B at offset X in zswap (zswap could also be
   full, if so, page B would then be IOed to X, then skip step 5.)
5. entry A is replaced by B in tree->rbroot, this doesn't affect the
   local reference held by zswap-shrink work
6. zswap-shrink work writes back A at X, and frees zswap entry A
7. swapin of slot X brings A in memory instead of B

The fix:
Once the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),
zswap-shrink work just checks that the local zswap_entry reference is
still the same as the one in the tree.  If it's not the same it means that
it's either been invalidated or replaced, in both cases the writeback is
aborted because the local entry contains stale data.

Reproducer:
I originally found this by running `stress` overnight to validate my work
on the zswap writeback mechanism, it manifested after hours on my test
machine.  The key to make it happen is having zswap writebacks, so
whatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do
the trick.

In order to reproduce this faster on a vm, I setup a system with ~100M of
available memory and a 500M swap file, then running `stress --vm 1
--vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens
of minutes.  One can speed things up even more by swinging
/sys/module/zswap/parameters/max_pool_percent up and down between, say, 20
and 1; this makes it reproduce in tens of seconds.  It's crucial to set
`--vm-stride` to something other than 4096 otherwise `stress` won't
realize that memory has been corrupted because all pages would have the
same data.

Statement: This vulnerability is a race condition in the zswap writeback path that can lead to memory corruption when a swap slot is reused while a writeback is still in progress.
A local unprivileged user can potentially trigger this issue by applying heavy memory pressure and causing frequent zswap evictions.
While exploitation for data leakage or privilege escalation is unlikely, the flaw can result in data integrity issues or system instability under specific conditions.

Affected upstream versions: 3.11
Fixed upstream versions: 0, 6.1.30, 6.3.4, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2cab13f500a6333bd2b853783ac76be9e4956f8a
CVE-2023-53180: kernel: wifi: ath12k: Avoid NULL pointer access during management transmit cleanup
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-15T00:00:00+00:00

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

wifi: ath12k: Avoid NULL pointer access during management transmit cleanup

Currently 'ar' reference is not added in skb_cb.
Though this is generally not used during transmit completion
callbacks, on interface removal the remaining idr cleanup callback
uses the ar pointer from skb_cb from management txmgmt_idr. Hence fill them
during transmit call for proper usage to avoid NULL pointer dereference.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1


Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.4.7, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7382d02160ef93c806fe1c1d4ef1fec445266747
CVE-2023-53181: kernel: dma-buf/dma-resv: Stop leaking on krealloc() failure
Component: kernel
Severity: Moderate
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-09-15T00:00:00+00:00

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

dma-buf/dma-resv: Stop leaking on krealloc() failure

Currently dma_resv_get_fences() will leak the previously
allocated array if the fence iteration got restarted and
the krealloc_array() fails.

Free the old array by hand, and make sure we still clear
the returned *fences so the caller won't end up accessing
freed memory. Some (but not all) of the callers of
dma_resv_get_fences() seem to still trawl through the
array even when dma_resv_get_fences() failed. And let's
zero out *num_fences as well for good measure.


Affected upstream versions: 5.16
Fixed upstream versions: 0, 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: 19e7b9f1f7e1cb92a4cc53b4c064f7fb4b1f1983