huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2025-38703: kernel: drm/xe: Make dma-fences compliant with the safe access rules
Component: kernel
Severity: Moderate
CWE: CWE-826 (Premature Release of Resource During Expected Lifetime)
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-04T00:00:00+00:00

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

drm/xe: Make dma-fences compliant with the safe access rules

Xe can free some of the data pointed to by the dma-fences it exports. Most
notably the timeline name can get freed if userspace closes the associated
submit queue. At the same time the fence could have been exported to a
third party (for example a sync_fence fd) which will then cause an use-
after-free on subsequent access.

To make this safe we need to make the driver compliant with the newly
documented dma-fence rules. Driver has to ensure a RCU grace period
between signalling a fence and freeing any data pointed to by said fence.

For the timeline name we simply make the queue be freed via kfree_rcu and
for the shared lock associated with multiple queues we add a RCU grace
period before freeing the per GT structure holding the lock.

Statement: This vulnerability can in theory be triggered by a non-privileged user as the primary requirements are:
1. The ability to trigger normal GPU operations (ex. creating and closing submission queues);
2. Read/Write permissions granted via the `video` and `render` groups (fairly standard for most operating systems);
3. Intel GPU hardware.

Affected upstream versions: 6.8
Fixed upstream versions: 0, 6.12.43, 6.15.11, 6.16.2, 6.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b17fcce70733c211cb5dabf54f4f9491920b1d92
CVE-2025-38718: kernel: sctp: linearize cloned gso packets in sctp_rcv
Component: kernel
Severity: Moderate
CWE: CWE-664 (Improper Control of a Resource Through its Lifetime)
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-09-04T00:00:00+00:00

A flaw use of uninitialized memory (uncontrolled and invisible by attacker) in the Linux kernel SCTP transport protocol was found in the way user triggers malicious SCTP packets. A remote user could use this flaw to crash the system. The bug actual only for systems where SCTP protocol being enabled and used.

Statement: A flaw in the SCTP receive path failed to linearize cloned GSO sk_buffs before accessing fraglists, leading to reads of uninitialized memory as reported by KMSAN. An attacker sending SCTP traffic can trigger incorrect processing and potentially cause a kernel denial of service on the target under specific RX conditions.
Stream Control Transmission Protocol (SCTP) is a transport-layer protocol (like TCP or UDP) primarily used in telecom signaling and some specialized applications. On most Linux systems it is disabled by default, and remote connectivity is only possible if SCTP support is enabled and listening services are configured (commonly using the IANA-assigned port 2905/tcp for M3UA or other protocol-specific ports). Therefore, the vulnerability is only exploitable when SCTP is enabled and reachable on the target system.
Although KMSAN reports this issue as use of uninitialized memory (which deterministically crashes with KMSAN enabled), on production kernels the impact is still availability-related.

Affected upstream versions: 4.8
Fixed upstream versions: 0, 5.10.241, 5.15.190, 5.4.297, 6.1.162, 6.12.43, 6.15.11, 6.16.2, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d0194e391bb493aa6cec56d177b14df6b29188d5
CVE-2025-38724: kernel: nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()
Component: kernel
Severity: Moderate
CWE: CWE-367 (Time-of-check Time-of-use (TOCTOU) Race Condition)
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-04T00:00:00+00:00

A vulnerability has been identified in the Linux kernel's Network File System (NFS) daemon that could allow for a Denial of Service and in worst case scenario Arbitrary Code Execution. This Use-After-Free flaw arises from a race condition when the kernel handles the confirmation of an NFS client identifier. If an NFS client is expiring while this confirmation is in progress, the system can attempt to use memory that is no longer allocated.

Statement: This flaw was rated as having a Moderate impact by the Red Hat Product Security team. Although it could ultimately lead to an arbitrary code execution the prerequisite of winning a race condition makes it complex to exploit, additionally the attacker would need to perform some reconnaissance of the victim's machine memory layout in order to be able to fully create a in-memory payload that could be further executed by the Linux Kernel NFS driver.

Affected upstream versions: 3.17
Fixed upstream versions: 0, 5.10.241, 5.15.190, 5.4.297, 6.1.149, 6.12.43, 6.15.11, 6.16.2, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3f252a73e81aa01660cb426735eab932e6182e8d
CVE-2025-38729: kernel: ALSA: usb-audio: Validate UAC3 power domain descriptors, too
Component: kernel
Severity: Moderate
CWE: CWE-125 (Out-of-bounds Read)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-09-04T00:00:00+00:00

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

ALSA: usb-audio: Validate UAC3 power domain descriptors, too

UAC3 power domain descriptors need to be verified with its variable
bLength for avoiding the unexpected OOB accesses by malicious
firmware, too.

Statement: A malicious or malformed USB Audio Class 3.0 device could provide a power-domain descriptor with an invalid bLength, leading the usb-audio parser to read past the end of the buffer. The fix adds explicit length checks for UAC3 power domain descriptors to prevent OOB access.

Affected upstream versions: 4.17
Fixed upstream versions: 0, 5.10.241, 5.15.190, 5.4.297, 6.1.149, 6.12.43, 6.15.11, 6.16.2, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 1666207ba0a5973735ef010812536adde6174e81
CVE-2025-38730: kernel: Linux kernel: Data corruption and system instability due to improper io_uring/net buffer handling
Component: kernel
Severity: Moderate
CWE: CWE-825 (Expired Pointer Dereference)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-09-04T00:00:00+00:00

A flaw was found in the Linux kernel's io_uring/net component. This vulnerability arises when ring provided buffers are partially committed during network operations, particularly when MSG_WAITALL is enabled or with streaming sockets. A local attacker could exploit this by causing multiple socket receives to access the same memory, leading to data corruption within applications. This could also result in system instability if buffer rings are unregistered before a retry operation completes.

Statement: This Moderate impact flaw in the Linux kernel's io_uring/net component affects Red Hat Enterprise Linux 9 and 10. A local attacker with a special group privilege may impact to a denial of service or a leak of kernel internal information through the shared ring buffer between user space and the kernel space processes.

Affected upstream versions: 6.4
Fixed upstream versions: 0, 6.12.44, 6.15.11, 6.16.2, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 3b53dc1c641f2884d4750fc25aaf6c36b90db606
CVE-2025-38731: kernel: drm/xe: Fix vm_bind_ioctl double free bug
Component: kernel
Severity: Moderate
CWE: CWE-763 (Release of Invalid Pointer or Reference)
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-05T00:00:00+00:00

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

drm/xe: Fix vm_bind_ioctl double free bug

If the argument check during an array bind fails, the bind_ops are freed
twice as seen below. Fix this by setting bind_ops to NULL after freeing.

==================================================================
BUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]
Free of addr ffff88813bb9b800 by task xe_vm/14198

CPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full)
Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021
Call Trace:
 <TASK>
 dump_stack_lvl+0x82/0xd0
 print_report+0xcb/0x610
 ? __virt_addr_valid+0x19a/0x300
 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]
 kasan_report_invalid_free+0xc8/0xf0
 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]
 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]
 check_slab_allocation+0x102/0x130
 kfree+0x10d/0x440
 ? should_fail_ex+0x57/0x2f0
 ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]
 xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]
 ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]
 ? __lock_acquire+0xab9/0x27f0
 ? lock_acquire+0x165/0x300
 ? drm_dev_enter+0x53/0xe0 [drm]
 ? find_held_lock+0x2b/0x80
 ? drm_dev_exit+0x30/0x50 [drm]
 ? drm_ioctl_kernel+0x128/0x1c0 [drm]
 drm_ioctl_kernel+0x128/0x1c0 [drm]
 ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]
 ? find_held_lock+0x2b/0x80
 ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]
 ? should_fail_ex+0x57/0x2f0
 ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]
 drm_ioctl+0x352/0x620 [drm]
 ? __pfx_drm_ioctl+0x10/0x10 [drm]
 ? __pfx_rpm_resume+0x10/0x10
 ? do_raw_spin_lock+0x11a/0x1b0
 ? find_held_lock+0x2b/0x80
 ? __pm_runtime_resume+0x61/0xc0
 ? rcu_is_watching+0x20/0x50
 ? trace_irq_enable.constprop.0+0xac/0xe0
 xe_drm_ioctl+0x91/0xc0 [xe]
 __x64_sys_ioctl+0xb2/0x100
 ? rcu_is_watching+0x20/0x50
 do_syscall_64+0x68/0x2e0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7fa9acb24ded

(cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a)

Statement: This vulnerability can in theory be triggered by a non-privileged user as the primary requirements are:
1. Access to GPU devices (usually possible if the user is part of the `video`/`render` groups);
2. The ability to interface with DRM ioctl operations (a standard GPU programming interface available to non-privileged users); 
3. Execute GPU virtual memory operations (creating address spaces and submitting bind operations).

Affected upstream versions: 6.15
Fixed upstream versions: 0, 6.16.4, 6.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 77a946bf1af0e8110ef6e243394217a17f9b7e33
CVE-2025-38737: kernel: cifs: Fix oops due to uninitialised variable
Component: kernel
Severity: Moderate
CWE: CWE-908 (Use of Uninitialized Resource)
CVSS v3: 6.5 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:H)
Public date: 2025-09-05T00:00:00+00:00

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

cifs: Fix oops due to uninitialised variable

Fix smb3_init_transform_rq() to initialise buffer to NULL before calling
netfs_alloc_folioq_buffer() as netfs assumes it can append to the buffer it
is given.  Setting it to NULL means it should start a fresh buffer, but the
value is currently undefined.

Statement: An unprivileged local user with access to an SMB3 share with encryption enabled can trigger this vulnerability through normal file operations, which due to the encryption will cause transform requests (i.e. encryption/decryption operations).

Affected upstream versions: 6.12
Fixed upstream versions: 0, 6.12.44, 6.16.4, 6.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 4931fe2dbe1cc0e7d350a4b51b0b330e43971d98
CVE-2025-3891: mod_auth_openidc: DoS via Empty POST in mod_auth_openidc with OIDCPreservePost Enabled
Component: mod_auth_openidc
Severity: Important
CWE: CWE-248 (Uncaught Exception)
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-04-29T11:37:07.680000+00:00

A flaw was found in the mod_auth_openidc module for Apache httpd. This flaw allows a remote, unauthenticated attacker to trigger a denial of service by sending an empty POST request when the OIDCPreservePost directive is enabled. The server crashes consistently, affecting availability.


Affected upstream versions: 2.0.0 < 2.4.13.1
Fixed upstream versions: 0:2.4.10-1.el9_6.2, 0:2.4.9.4-1.el9_0.3, 0:2.4.9.4-1.el9_2.3, 0:2.4.9.4-4.el9_4.2, 2.4.13.1, 8020020250612174445.4cda2c84, 8040020250618101351.522a0ee4, 8060020250617090503.ad008a3a, 8080020250617090716.63b34585, 8100020250426100353.489197e6
Upstream repository: https://github.com/OpenIDC/mod_auth_openidc
Upstream fix commit: 6a0b5f66c87184dfe0e4400f6bdd46a82dc0ec2b
CVE-2025-39682: kernel: tls: fix handling of zero-length records on the rx_list
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:H)
Public date: 2025-09-05T00:00:00+00:00

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

tls: fix handling of zero-length records on the rx_list

Each recvmsg() call must process either
 - only contiguous DATA records (any number of them)
 - one non-DATA record

If the next record has different type than what has already been
processed we break out of the main processing loop. If the record
has already been decrypted (which may be the case for TLS 1.3 where
we don't know type until decryption) we queue the pending record
to the rx_list. Next recvmsg() will pick it up from there.

Queuing the skb to rx_list after zero-copy decrypt is not possible,
since in that case we decrypted directly to the user space buffer,
and we don't have an skb to queue (darg.skb points to the ciphertext
skb for access to metadata like length).

Only data records are allowed zero-copy, and we break the processing
loop after each non-data record. So we should never zero-copy and
then find out that the record type has changed. The corner case
we missed is when the initial record comes from rx_list, and it's
zero length.

Statement: A logic bug in the kTLS receive path mishandles zero-length records taken from the rx_list, allowing a mixed record-type sequence to slip past the per-recvmsg() type constraint and proceed to data processing. The fix initializes and checks the per-call content type (using 0 as “unset”) and bails out when a non-DATA record is encountered after DATA. This can be remotely triggered only when kernel TLS (CONFIG_TLS with the TLS ULP) is in use.
This issue can only be triggered when the kernel TLS ULP (kTLS, enabled via CONFIG_TLS and attached to TCP sockets with SOL_TLS) is in use

Affected upstream versions: 6.0
Fixed upstream versions: 0, 6.1.149, 6.12.44, 6.16.4, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 2902c3ebcca52ca845c03182000e8d71d3a5196f
CVE-2025-39694: kernel: s390/sclp: Fix SCCB present check
Component: kernel
Severity: Moderate
CWE: CWE-1285 (Improper Validation of Specified Index, Position, or Offset in Input)
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-05T00:00:00+00:00

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

s390/sclp: Fix SCCB present check

Tracing code called by the SCLP interrupt handler contains early exits
if the SCCB address associated with an interrupt is NULL. This check is
performed after physical to virtual address translation.

If the kernel identity mapping does not start at address zero, the
resulting virtual address is never zero, so that the NULL checks won't
work. Subsequently this may result in incorrect accesses to the first
page of the identity mapping.

Fix this by introducing a function that handles the NULL case before
address translation.

Statement: This vulnerability does not affect Red Hat Enterprise Linux versions 9.4 and prior.
On s390, the SCLP interrupt tracing path translated the SCCB interrupt address to a virtual address before checking for NULL. If the kernel’s identity mapping does not start at 0, the post-translation pointer is never zero, so the NULL check fails and the code may touch the first page of the identity map, leading to a kernel crash.
This issue is specific to the s390 architecture and does not affect other platforms.

Affected upstream versions: 5.16
Fixed upstream versions: 0, 6.1.149, 6.12.44, 6.16.4, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: aa5073ac1a2a274812f3b04c278992e68ff67cc7
CVE-2025-39697: kernel: NFS: Fix a race when updating an existing write
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
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-09-05T00:00:00+00:00

A flaw use after free in the Linux kernel NFS functionality was found in the way connected user sends malicious data to the server. A remote user could use this flaw to crash the system.

Statement: A race condition in the NFS write path allowed a request to be removed after it was checked but before the page-group lock was taken. The fix acquires the page-group lock earlier and holds it across request removal, preventing use-after-state races. This can be triggered by a client with write access to an export and may lead to a kernel crash (remote DoS).
This race condition is difficult to trigger in practice, as it requires several conditions to align (concurrent write activity and timing), and there is no evidence of remote control over memory contents. Therefore the most likely outcome is a denial of service (Availability: High), with Confidentiality and Integrity unaffected.

Affected upstream versions: 4.14
Fixed upstream versions: 0, 5.10.242, 5.15.191, 6.1.150, 6.12.44, 6.16.4, 6.17, 6.6.104
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 0ff42a32784e0f2cb46a46da8e9f473538c13e1b
CVE-2025-39698: kernel: io_uring/futex: ensure io_futex_wait() cleans up properly on failure
Component: kernel
Severity: Moderate
CWE: CWE-416 (Use After Free)
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-05T00:00:00+00:00

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

io_uring/futex: ensure io_futex_wait() cleans up properly on failure

The io_futex_data is allocated upfront and assigned to the io_kiocb
async_data field, but the request isn't marked with REQ_F_ASYNC_DATA
at that point. Those two should always go together, as the flag tells
io_uring whether the field is valid or not.

Additionally, on failure cleanup, the futex handler frees the data but
does not clear ->async_data. Clear the data and the flag in the error
path as well.

Thanks to Trend Micro Zero Day Initiative and particularly ReDress for
reporting this.

Statement: A flaw in io_uring’s futex path freed io_futex_data on error but left req->async_data and the REQ_F_ASYNC_DATA flag inconsistent, creating a window for use-after-free.
This issue is reachable by any unprivileged local user via io_uring futex operations. The most plausible impact is denial of service, since the freed structure is small and not directly attacker-controlled, making exploitation for privilege escalation very unlikely. Still, as with any use-after-free in kernel space, a worst-case impact would be privileges escalation.

Affected upstream versions: 6.7
Fixed upstream versions: 0, 6.12.44, 6.16.4, 6.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: d9f93172820a53ab42c4b0e5e65291f4f9d00ad2
CVE-2025-39702: kernel: ipv6: sr: Fix MAC comparison to be constant-time
Component: kernel
Severity: Moderate
CWE: CWE-208 (Observable Timing Discrepancy)
CVSS v3: 7.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H)
Public date: 2025-09-05T00:00:00+00:00

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

ipv6: sr: Fix MAC comparison to be constant-time

To prevent timing attacks, MACs need to be compared in constant time.
Use the appropriate helper function for this.


Affected upstream versions: 4.10
Fixed upstream versions: 0, 5.10.249, 5.15.190, 6.1.149, 6.12.44, 6.16.4, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ff55a452d56490047f5233cc48c5d933f8586884
CVE-2025-39718: kernel: vsock/virtio: Validate length in packet header before skb_put()
Component: kernel
Severity: Moderate
CWE: CWE-787 (Out-of-bounds Write)
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-05T00:00:00+00:00

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

vsock/virtio: Validate length in packet header before skb_put()

When receiving a vsock packet in the guest, only the virtqueue buffer
size is validated prior to virtio_vsock_skb_rx_put(). Unfortunately,
virtio_vsock_skb_rx_put() uses the length from the packet header as the
length argument to skb_put(), potentially resulting in SKB overflow if
the host has gone wonky.

Validate the length as advertised by the packet header before calling
virtio_vsock_skb_rx_put().

Statement: A flaw in the virtio vsock receive path trusted the packet header’s len field and passed it to skb_put() without first ensuring it fit within the received buffer, enabling an out-of-bounds write if the host provides a malformed header (means attack from host to client). The patch validates the header-advertised payload length before calling virtio_vsock_skb_rx_put(). This is adjacent-vector and host-to-guest exploitable.
This vulnerability can only be exploited in environments where virtio-vsock is in use (i.e., when CONFIG_VIRTIO_VSOCKETS is enabled and guest-to-host communication via vsock is active).

Affected upstream versions: 6.1.63 < 6.1.149, 6.3
Fixed upstream versions: 0, 6.1.149, 6.12.44, 6.16.4, 6.17, 6.6.103
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 969b06bd8b7560efb100a34227619e7d318fbe05
CVE-2025-39727: kernel: mm: swap: fix potential buffer overflow in setup_clusters()
Component: kernel
Severity: Moderate
CWE: CWE-120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'))
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-09-07T00:00:00+00:00

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

mm: swap: fix potential buffer overflow in setup_clusters()

In setup_swap_map(), we only ensure badpages are in range (0, last_page]. 
As maxpages might be < last_page, setup_clusters() will encounter a buffer
overflow when a badpage is >= maxpages.

Only call inc_cluster_info_page() for badpage which is < maxpages to fix
the issue.


Affected upstream versions: 6.12
Fixed upstream versions: 0, 6.12.42, 6.15.10, 6.16.1, 6.17
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 91b370800b3f2b3dda244c0ab06719c4971190a5
CVE-2025-39730: kernel: NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()
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:N/I:N/A:H)
Public date: 2025-09-07T00:00:00+00:00

A flaw out of boundary read in the Linux kernel NFS functionality was found in the way connected user sends malicious data to the server. A remote user could use this flaw to crash the system.

Statement: A flaw was found in the NFS server implementation where nfs_fh_to_dentry() failed to properly validate the minimal filehandle length before accessing the embedded structure. An attacker with access to an exported NFS share could send a crafted filehandle, leading to out-of-bounds memory access and a potential kernel crash. This issue results in a remote denial of service against the NFS server.
This flaw is limited to a missing bounds check in nfs_fh_to_dentry(), which causes an out-of-bounds read and a kernel crash.

Affected upstream versions: 4.13
Fixed upstream versions: 0, 5.10.241, 5.15.190, 5.4.297, 6.1.148, 6.12.42, 6.15.10, 6.16.1, 6.17, 6.6.102
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7f8eca87fef7519e9c41f3258f25ebc2752247ee