huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2023-53677: kernel: drm/i915: Fix memory leaks in i915 selftests
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-10-07T00:00:00+00:00

A memory leak flaw was found in the Linux kernel's Intel i915 graphics driver in the selftest page allocation logic. A local user can trigger this issue when running i915 selftests and the fake_get_pages function encounters errors, causing the function to return without freeing previously allocated memory. This results in a permanent memory leak leading to resource exhaustion and denial of service.

Statement: The fake_get_pages function in the i915 selftest code allocates various resources but fails to free them when encountering errors in certain paths. When the function returns early due to error conditions, allocated pages and other structures remain unreleased. Since selftests are typically run during driver testing or validation rather than normal operation, the practical impact is limited to development and testing scenarios. However, if selftests are executed in production environments or during automated testing cycles, the accumulated leaks could cause memory exhaustion.

Affected upstream versions: 6.3
Fixed upstream versions: 0, 6.3.2, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 596d7308e189a3230bf33d667b64acc73846c2d0
CVE-2023-53678: kernel: drm/i915: Fix system suspend without fbdev being initialized
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

A NULL pointer dereference was found in the Linux kernel Intel i915 graphics driver's framebuffer device suspend handling. On platforms without display hardware where fbdev is not initialized, a local user with privileges to initiate system suspend can trigger the suspend path, causing the driver to attempt locking a mutex in the uninitialized fbdev structure, which results in a kernel NULL pointer dereference and denial of service through system crash.

Statement: The issue arises because the i915 driver's suspend path unconditionally attempts to suspend the framebuffer device without checking whether fbdev was successfully initialized. On platforms lacking display hardware (such as certain server or embedded configurations), fbdev initialization is skipped entirely, leaving the structure NULL. When system suspend is initiated through standard mechanisms (writing to /sys/power/state), the power management subsystem calls into the i915 driver's suspend handler, which then calls intel_fbdev_set_suspend(). This function attempts to acquire a mutex at offset 0x1c8 within the NULL fbdev structure, triggering an immediate kernel NULL pointer dereference. The crash occurs reliably on affected hardware configurations whenever suspend is attempted. While this is a severe availability issue causing complete system failure, exploitation is limited to users with privileges to initiate system suspend operations, and there is no memory corruption or information disclosure beyond the crash itself.

Affected upstream versions: 6.1
Fixed upstream versions: 0, 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: 27b5871abd5cc068c549fd23062c82e257fc0b9c
CVE-2023-53680: kernel: NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL
Component: kernel
Severity: Moderate
CVSS v3: 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/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:

NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGAL

OPDESC() simply indexes into nfsd4_ops[] by the op's operation
number, without range checking that value. It assumes callers are
careful to avoid calling it with an out-of-bounds opnum value.

nfsd4_decode_compound() is not so careful, and can invoke OPDESC()
with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the end
of nfsd4_ops[].

Statement: NFSD could call OPDESC() with opnum == OP_ILLEGAL, indexing past nfsd4_ops[] and causing an out-of-bounds read leading to a crash. A remote unauthenticated NFSv4 client could trigger this via a crafted COMPOUND, impacting availability of the NFS server. The fix sets op->opdesc = NULL, assigns opdesc only when opnum is in range, and removes the unconditional OPDESC() call.

Affected upstream versions: 4.14
Fixed upstream versions: 0, 5.10.220, 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: 50827896c365e0f6c8b55ed56d444dafd87c92c5
CVE-2023-53687: kernel: tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk
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:

tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clk

When the best clk is searched, we iterate over all possible clk.

If we find a better match, the previous one, if any, needs to be freed.
If a better match has already been found, we still need to free the new
one, otherwise it leaks.


Affected upstream versions: 3.3
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: 933e5b2998bc3a527d15efbf1e97c9e63297aa3c
CVE-2023-53696: kernel: scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()
Component: kernel
Severity: Low
CWE: CWE-772 (Missing Release of Resource after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-22T00:00:00+00:00

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

scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()

There is a memory leak reported by kmemleak:

  unreferenced object 0xffffc900003f0000 (size 12288):
    comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)
    hex dump (first 32 bytes):
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    backtrace:
      [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110
      [<0000000001906886>] __vmalloc_node+0xbd/0x150
      [<000000005bb4dc34>] vmalloc+0x25/0x30
      [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]
      [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]
      [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0

The root cause is traced to an error-handling path in qla2x00_probe_one()
when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is
used to record the port information and it is allocated in
qla2x00_create_host(). However, it is not released in the error handling
path "probe_failed".

Fix this by freeing the memory of "scan.l" when an error occurs in the
adapter initialization process.


Affected upstream versions: 4.16
Fixed upstream versions: 0, 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: ae73c4dd48f2c79d515d509a0cbe9efb0a197f44
CVE-2023-53697: kernel: nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()
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-10-22T00:00:00+00:00

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

nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()

Memory pointed by 'nd_pmu->pmu.attr_groups' is allocated in function
'register_nvdimm_pmu' and is lost after 'kfree(nd_pmu)' call in function
'unregister_nvdimm_pmu'.


Affected upstream versions: 5.18
Fixed upstream versions: 0, 6.1.53, 6.4.16, 6.5.3, 6.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 500a6ff9c2a81348fe0f04e2deb758145e8ab94e
CVE-2023-53698: kernel: xsk: fix refcount underflow in error path
Component: kernel
Severity: Moderate
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-22T00:00:00+00:00

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

xsk: fix refcount underflow in error path

Fix a refcount underflow problem reported by syzbot that can happen
when a system is running out of memory. If xp_alloc_tx_descs() fails,
and it can only fail due to not having enough memory, then the error
path is triggered. In this error path, the refcount of the pool is
decremented as it has incremented before. However, the reference to
the pool in the socket was not nulled. This means that when the socket
is closed later, the socket teardown logic will think that there is a
pool attached to the socket and try to decrease the refcount again,
leading to a refcount underflow.

I chose this fix as it involved adding just a single line. Another
option would have been to move xp_get_pool() and the assignment of
xs->pool to after the if-statement and using xs_umem->pool instead of
xs->pool in the whole if-statement resulting in somewhat simpler code,
but this would have led to much more churn in the code base perhaps
making it harder to backport.

Statement: In xsk_bind(), if xp_alloc_tx_descs() fails (OOM), the error path decremented the pool’s refcount via xp_put_pool(xs->pool) but did not null out xs->pool. On socket teardown, the code would attempt another put, causing a refcount underflow and potential kernel BUG or use-after-free. The fix sets xs->pool = NULL after the first put, preventing the double decrement. Practical triggering typically requires privileged ability to create/bind AF_XDP sockets and induce low-memory conditions.

Affected upstream versions: 5.15.47 < 5.15.127, 5.17.15 < 5.18, 5.18
Fixed upstream versions: 0, 5.15.127, 5.18, 6.1.46, 6.4.11, 6.5
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 789fcd94c9cac133dd4d96e193188661aca9f6c3
CVE-2023-53702: kernel: s390/crypto: use vector instructions only if available for ChaCha20
Component: kernel
Severity: Low
CWE: CWE-252 (Unchecked Return Value)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-10-22T00:00:00+00:00

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

s390/crypto: use vector instructions only if available for ChaCha20

Commit 349d03ffd5f6 ("crypto: s390 - add crypto library interface for
ChaCha20") added a library interface to the s390 specific ChaCha20
implementation. However no check was added to verify if the required
facilities are installed before branching into the assembler code.

If compiled into the kernel, this will lead to the following crash,
if vector instructions are not available:

data exception: 0007 ilc:3 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7+ #11
Hardware name: IBM 3931 A01 704 (KVM/Linux)
Krnl PSW : 0704e00180000000 000000001857277a (chacha20_vx+0x32/0x818)
           R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3
Krnl GPRS: 0000037f0000000a ffffffffffffff60 000000008184b000 0000000019f5c8e6
           0000000000000109 0000037fffb13c58 0000037fffb13c78 0000000019bb1780
           0000037fffb13c58 0000000019f5c8e6 000000008184b000 0000000000000109
           00000000802d8000 0000000000000109 0000000018571ebc 0000037fffb13718
Krnl Code: 000000001857276a: c07000b1f80b        larl    %r7,0000000019bb1780
           0000000018572770: a708000a            lhi     %r0,10
          #0000000018572774: e78950000c36        vlm     %v24,%v25,0(%r5),0
          >000000001857277a: e7a060000806        vl      %v26,0(%r6),0
           0000000018572780: e7bf70004c36        vlm     %v27,%v31,0(%r7),4
           0000000018572786: e70b00000456        vlr     %v0,%v27
           000000001857278c: e71800000456        vlr     %v1,%v24
           0000000018572792: e74b00000456        vlr     %v4,%v27
Call Trace:
 [<000000001857277a>] chacha20_vx+0x32/0x818
Last Breaking-Event-Address:
 [<0000000018571eb6>] chacha20_crypt_s390.constprop.0+0x6e/0xd8
---[ end trace 0000000000000000 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

Fix this by adding a missing MACHINE_HAS_VX check.

[agordeev@linux.ibm.com: remove duplicates in commit message]


Affected upstream versions: 5.19
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: 25e8d30507aa2f251152df1af7809e85b5538f4a
CVE-2023-53704: kernel: clk: imx: clk-imx8mp: improve error handling in imx8mp_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-10-22T00:00:00+00:00

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

clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()

Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc()
which can automatically release the related memory when the device
or driver is removed or unloaded to avoid potential memory leak.

In this case, iounmap(anatop_base) in line 427,433 are removed
as manual release is not required.

Besides, referring to clk-imx8mq.c, check the return code of
of_clk_add_hw_provider, if it returns negtive, print error info
and unregister hws, which makes the program more robust.


Affected upstream versions: 5.6
Fixed upstream versions: 0, 5.10.188, 5.15.121, 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: cb047c13bbf9018693ae31f03a5a26b212d02f13
CVE-2023-53705: kernel: ipv6: Fix out-of-bounds access in ipv6_find_tlv()
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:H)
Public date: 2025-10-22T00:00:00+00:00

An out of bounds (OOB) memory access flaw was found in the Linux kernel's ipv6 network subsystem. This could allow a local attacker to crash the system or leak kernel internal information.

Statement: The function ipv6_find_tlv() parsed IPv6 extension headers without checking that at least two bytes were available before reading the option length field.
An attacker could send a malformed IPv6 packet with a truncated extension header, causing an out-of-bounds read and potential kernel crash or memory fault while parsing.
The fix adds a length check (if (len < 2) goto bad;) before accessing the second byte, preventing buffer overrun.
This issue is remotely triggerable via network traffic and can lead to kernel panic (DoS) or, in rare cases, information leakage through speculative execution paths.

Affected upstream versions: 2.6.19
Fixed upstream versions: 0, 4.14.316, 4.19.284, 5.10.181, 5.15.114, 5.4.244, 6.1.31, 6.3.5, 6.4
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 59e656d0d4a84ea0ee9a39c6f69160a3effccc94
CVE-2023-53708: kernel: ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objects
Component: kernel
Severity: Low
CVSS v3: 4 (CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)
Public date: 2025-10-22T00:00:00+00:00

A memory leak was found in the Linux kernel's ACPI x86 suspend-to-idle implementation in the AMD Low Power S0 (LPS0) DSM evaluation code. A system with malformed ACPI firmware that returns multiple ACPI_TYPE_PACKAGE objects during _DSM evaluation can trigger repeated memory allocations that are never freed. This leads to gradual memory exhaustion and potential denial of service.

Statement: The AMD LPS0 DSM handler expects a single package object but doesn't guard against firmware returning multiples. Each extra package leaks memory.

Affected upstream versions: 5.11
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: 7b7964cd9db30bc84808a40d13a0633b4313f149
CVE-2023-53710: kernel: wifi: mt76: mt7921: fix error code of return in mt7921_acpi_read
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-22T00:00:00+00:00

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

wifi: mt76: mt7921: fix error code of return in mt7921_acpi_read

Kernel NULL pointer dereference when ACPI SAR table isn't implemented well.
Fix the error code of return to mark the ACPI SAR table as invalid.

[    5.077128] mt7921e 0000:06:00.0: sar cnt = 0
[    5.077381] BUG: kernel NULL pointer dereference, address:
0000000000000004
[    5.077630] #PF: supervisor read access in kernel mode
[    5.077883] #PF: error_code(0x0000) - not-present page
[    5.078138] PGD 0 P4D 0
[    5.078398] Oops: 0000 [#1] PREEMPT SMP NOPTI
[    5.079202] RIP: 0010:mt7921_init_acpi_sar+0x106/0x220
[mt7921_common]
...
[    5.080786] Call Trace:
[    5.080786]  <TASK>
[    5.080786]  mt7921_register_device+0x37d/0x490 [mt7921_common]
[    5.080786]  mt7921_pci_probe.part.0+0x2ee/0x310 [mt7921e]
[    5.080786]  mt7921_pci_probe+0x52/0x70 [mt7921e]
[    5.080786]  local_pci_probe+0x47/0x90
[    5.080786]  pci_call_probe+0x55/0x190
[    5.080786]  pci_device_probe+0x84/0x120


Affected upstream versions: 6.0
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: 2a9a5f88e0da71c8e4f30aacbda45b1a1af5469d
CVE-2023-53711: kernel: NFS: Fix a potential data corruption
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-22T00:00:00+00:00

A logic error was found in the Linux kernel's NFS client implementation in the write request retransmission handling for O_DIRECT operations. 
A local user performing direct I/O writes over NFS can trigger this issue when the server completes writes synchronously and network conditions require retransmission, causing subrequests to not be properly rejoined to the head request before retransmit. This results in data corruption where written data may not be correctly persisted to the server.

Statement: NFS write operations can be split into multiple subrequests, which must be rejoined to the head request before any retransmission occurs. When an NFS server handles a write synchronously rather than through the commit mechanism, the head request bypasses the normal commit list path. If retransmission becomes necessary due to network issues, the code failed to add the head back to the retransmission list, leaving subrequests orphaned. This causes incomplete or corrupted writes to the server without returning errors to the application. Triggering the bug requires local access to an NFS-mounted filesystem using O_DIRECT, combined with server-side synchronous write behavior and network conditions that prompt retransmission.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.195, 5.15.132, 6.1.54, 6.5.4, 6.6
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4185605cd0f72ec8bf8b423aacd94cd5ee13bbcf
CVE-2023-53713: kernel: arm64: sme: Use STR P to clear FFR context field in streaming SVE mode
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
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-10-22T00:00:00+00:00

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

arm64: sme: Use STR P to clear FFR context field in streaming SVE mode

The FFR is a predicate register which can vary between 16 and 256 bits
in size depending upon the configured vector length. When saving the
SVE state in streaming SVE mode, the FFR register is inaccessible and
so commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simply
clears the FFR field of the in-memory context structure. Unfortunately,
it achieves this using an unconditional 8-byte store and so if the SME
vector length is anything other than 64 bytes in size we will either
fail to clear the entire field or, worse, we will corrupt memory
immediately following the structure. This has led to intermittent kfence
splats in CI [1] and can trigger kmalloc Redzone corruption messages
when running the 'fp-stress' kselftest:

 | =============================================================================
 | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten
 | -----------------------------------------------------------------------------
 |
 | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc
 | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531
 |  __kmalloc+0x8c/0xcc
 |  do_sme_acc+0x9c/0x220
 |  ...

Replace the 8-byte store with a store of a predicate register which has
been zero-initialised with PFALSE, ensuring that the entire field is
cleared in memory.

[1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com


Affected upstream versions: 5.16
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: 97669214944e80d3756657c21c4f286f3da6a423
CVE-2023-53717: kernel: wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
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-10-22T00:00:00+00:00

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

wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()

Fix a stack-out-of-bounds write that occurs in a WMI response callback
function that is called after a timeout occurs in ath9k_wmi_cmd().
The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer that
could no longer be valid when a timeout occurs. Set wmi->last_seq_id to
0 when a timeout occurred.

Found by a modified version of syzkaller.

BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx
Write of size 4
Call Trace:
 memcpy
 ath9k_wmi_ctrl_rx
 ath9k_htc_rx_msg
 ath9k_hif_usb_reg_in_cb
 __usb_hcd_giveback_urb
 usb_hcd_giveback_urb
 dummy_timer
 call_timer_fn
 run_timer_softirq
 __do_softirq
 irq_exit_rcu
 sysvec_apic_timer_interrupt

Statement: ath9k_wmi_cmd() could time out while a late WMI response still arrived and wrote into wmi->cmd_rsp_buf, which was a stack buffer no longer valid, causing a stack out-of-bounds write. The patch sets wmi->last_seq_id = 0 on timeout so late responses are discarded, preventing the write to a stale stack buffer. Primary impact is availability (kernel crash), with potential memory corruption in worst case.
Triggering this issue typically requires local access with a connected AR9271 or ath9k_htc USB Wi-Fi dongle, along with the ability to induce command timeouts within the driver.

Affected upstream versions: 2.6.35
Fixed upstream versions: 0, 4.14.308, 4.19.276, 5.10.173, 5.15.99, 5.4.235, 6.1.16, 6.2.3, 6.3
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 89a33c3c847b19b19205cde1d924df2a6c70d8eb