deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-40308
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: bcsp: receive data only if registered

Currently, bcsp_recv() can be called even when the BCSP protocol has not
been registered. This leads to a NULL pointer dereference, as shown in
the following stack trace:

    KASAN: null-ptr-deref in range [0x[PII_REDACTED]000108-0x[PII_REDACTED]00010f]
    RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590
    Call Trace:
     <TASK>
     hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627
     tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290
     tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706
     vfs_ioctl fs/ioctl.c:51 [inline]
     __do_sys_ioctl fs/ioctl.c:907 [inline]
     __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
     do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94
     entry_SYSCALL_64_after_hwframe+0x77/0x7f

To prevent this, ensure that the HCI_UART_REGISTERED flag is set before
processing received data. If the protocol is not registered, return
-EUNATCH.
References: https://git.kernel.org/stable/c/164586725b47f9d61912e6bf17dbaffeff11710b; https://git.kernel.org/stable/c/39a7d40314b6288cfa2d13269275e9247a7a055a; https://git.kernel.org/stable/c/55c1519fca830f59a10bbf9aa8209c87b06cf7bc
CVE: CVE-2025-40310
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_sw

There is race in amdgpu_amdkfd_device_fini_sw and interrupt.
if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and
  kfree(kfd), and KGD interrupt generated.

kernel panic log:

BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSP

PGD d78c68067 P4D d78c68067

kfd kfd: amdgpu: Allocated 3969056 bytes on gart

PUD 1465b8067 PMD @

Oops: @002 [#1] SMP NOPTI

kfd kfd: amdgpu: Total number of KFD nodes to be created: 4
CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE K

RIP: 0010:_raw_spin_lock_irqsave+0x12/0x40

Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 <fO> OF b1 17 75 Ba 4c 89 e@ 41 Sc

89 c6 e8 07 38 5d

RSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046

RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: [PII_REDACTED]
[PII_REDACTED] RSI: ffff8883bb623e00 RDI: [PII_REDACTED]
ffff8883bb000000 RO8: ffff[PII_REDACTED]20 ROO: ffff[PII_REDACTED]20
[PII_REDACTED] R11: [PII_REDACTED] R12: [PII_REDACTED]
ffff888F2b97da0@ R14: @[PII_REDACTED]00098 R15: ffff8883babdfo00

CS: 010 DS: 0000 ES: 0000 CRO: [PII_REDACTED]

CR2: [PII_REDACTED] CR3: 0000000e7cae2006 CR4:[PII_REDACTED]770ce0
[PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
[PII_REDACTED] DR6: 00000000fffeO7FO DR7: [PII_REDACTED]

PKRU: 55555554

Call Trace:

<IRQ>

kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]

? amdgpu_fence_process+0xa4/0x150 [amdgpu]

kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tErace

amdgpu_irq_dispatch+0x165/0x210 [amdgpu]

amdgpu_ih_process+0x80/0x100 [amdgpu]

amdgpu: Virtual CRAT table created for GPU

amdgpu_irq_handler+0x1f/@x60 [amdgpu]

__handle_irq_event_percpu+0x3d/0x170

amdgpu: Topology: Add dGPU node [0x74a2:0x1002]

handle_irq_event+0x5a/@xcO

handle_edge_irq+0x93/0x240

kfd kfd: amdgpu: KFD node 1 partition @ size 49148M

asm_call_irq_on_stack+0xf/@x20

</IRQ>

common_interrupt+0xb3/0x130

asm_common_interrupt+0x1le/0x40

5.10.134-010.a1i5000.a18.x86_64 #1
References: https://git.kernel.org/stable/c/2f89a2d15550b653caaeeab7ab68c4d7583fd4fe; https://git.kernel.org/stable/c/93f8d67ef8b50334a26129df4da5a4cb60ad4090; https://git.kernel.org/stable/c/99d7181bca34e96fbf61bdb6844918bdd4df2814
CVE: CVE-2025-40311
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/habanalabs: support mapping cb with vmalloc-backed coherent memory

When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return
addresses from the vmalloc range. If such an address is mapped without
VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the
VM_PFNMAP restriction.

Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP
in the VMA before mapping. This ensures safe mapping and avoids kernel
crashes. The memory is still driver-allocated and cannot be accessed
directly by userspace.
References: https://git.kernel.org/stable/c/513024d5a0e34fd34247043f1876b6138ca52847; https://git.kernel.org/stable/c/73c7c2cdb442fc4160d2a2a4bfffbd162af06cb9; https://git.kernel.org/stable/c/7ec8ac9f73d4a9438c2186768d6de27ace37531e
CVE: CVE-2025-40312
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: Verify inode mode when loading from disk

The inode mode loaded from corrupted disk can be invalid. Do like what
commit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")
does.
References: https://git.kernel.org/stable/c/1795277a4e98d82e6451544d43695540cee042ea; https://git.kernel.org/stable/c/19cce65709a8a[PII_REDACTED]028d9004e28e85bd5; https://git.kernel.org/stable/c/2870a7dec49ccdc3f6ae35da8f5d6737f21133a8
CVE: CVE-2025-40313
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

ntfs3: pretend $Extend records as regular files

Since commit af153bb63a33 ("vfs: catch invalid modes in may_open()")
requires any inode be one of S_IFDIR/S_IFLNK/S_IFREG/S_IFCHR/S_IFBLK/
S_IFIFO/S_IFSOCK type, use S_IFREG for $Extend records.
References: https://git.kernel.org/stable/c/17249b2a65274f73ed68bcd1604e08a60fd8a278; https://git.kernel.org/stable/c/37f65e68ba9852dc51c78dbb54a9881c3f0fe4f7; https://git.kernel.org/stable/c/4e8011ffec79717e5fdac43a7e79faf811a384b7
CVE: CVE-2025-40314
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget

In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget
structure (pdev->gadget) was freed before its endpoints.
The endpoints are linked via the ep_list in the gadget structure.
Freeing the gadget first leaves dangling pointers in the endpoint list.
When the endpoints are subsequently freed, this results in a use-after-free.

Fix:
By separating the usb_del_gadget_udc() operation into distinct "del" and
"put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the
final release of the gadget structure with usb_put_gadget().

A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure
 only after freeing endpoints").
References: https://git.kernel.org/stable/c/0cf9a50af91fbdac3849f8d950e883a3eaa3ecea; https://git.kernel.org/stable/c/37158ce6ba964b62d1e3eebd11f03c6900a52dd1; https://git.kernel.org/stable/c/87c5ff5615dc0a37167e8faf3adeeddc6f1344a3
CVE: CVE-2025-40315
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Fix epfile null pointer access after ep enable.

A race condition occurs when ffs_func_eps_enable() runs concurrently
with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()
sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leading
to a NULL pointer dereference when accessing epfile->ep in
ffs_func_eps_enable() after successful usb_ep_enable().

The ffs->epfiles pointer is set to NULL in both ffs_data_clear() and
ffs_data_close() functions, and its modification is protected by the
spinlock ffs->eps_lock. And the whole ffs_func_eps_enable() function
is also protected by ffs->eps_lock.

Thus, add NULL pointer handling for ffs->epfiles in the
ffs_func_eps_enable() function to fix issues
References: https://git.kernel.org/stable/c/1c0dbd240be3f87cac321b14e17979b7e9cb6a8f; https://git.kernel.org/stable/c/30880e9df27332403dd638a82c27921134b3630b; https://git.kernel.org/stable/c/9ec40fba7357df2d36f4c2e2f3b9b1a4fba0a272
CVE: CVE-2025-40316
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Fix device use-after-free on unbind

A recent change fixed device reference leaks when looking up drm
platform device driver data during bind() but failed to remove a partial
fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix
kobject put for component sub-drivers").

This results in a reference imbalance on component bind() failures and
on unbind() which could lead to a user-after-free.

Make sure to only drop the references after retrieving the driver data
by effectively reverting the previous partial fix.

Note that holding a reference to a device does not prevent its driver
data from going away so there is no point in keeping the reference.
References: https://git.kernel.org/stable/c/0142fe895986addf35885b43440718e567121155; https://git.kernel.org/stable/c/8ba827e09eb586e952d10e39406fa02d10bb591e; https://git.kernel.org/stable/c/926d002e6d7e2f1fd5c1b53cf6208153ee7d380d
CVE: CVE-2025-40317
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

regmap: slimbus: fix bus_context pointer in regmap init calls

Commit 4e65bda8273c ("ASoC: wcd934x: fix error handling in
wcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.
That commit breaks audio playback, for instance, on sdm845 Thundercomm
Dragonboard 845c board:

 Unable to handle kernel paging request at virtual address ffff8000847cbad4
 ...
 CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT
 Hardware name: Thundercomm Dragonboard 845c (DT)
 ...
 Call trace:
  slim_xfer_msg+0x24/0x1ac [slimbus] (P)
  slim_read+0x48/0x74 [slimbus]
  regmap_slimbus_read+0x18/0x24 [regmap_slimbus]
  _regmap_raw_read+0xe8/0x174
  _regmap_bus_read+0x44/0x80
  _regmap_read+0x60/0xd8
  _regmap_update_bits+0xf4/0x140
  _regmap_select_page+0xa8/0x124
  _regmap_raw_write_impl+0x3b8/0x65c
  _regmap_bus_raw_write+0x60/0x80
  _regmap_write+0x58/0xc0
  regmap_write+0x4c/0x80
  wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x]
  snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core]
  __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core]
  dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core]
  dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core]
  snd_pcm_hw_params+0x124/0x464 [snd_pcm]
  snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm]
  snd_pcm_ioctl+0x34/0x4c [snd_pcm]
  __arm64_sys_ioctl+0xac/0x104
  invoke_syscall+0x48/0x104
  el0_svc_common.constprop.0+0x40/0xe0
  do_el0_svc+0x1c/0x28
  el0_svc+0x34/0xec
  el0t_64_sync_handler+0xa0/0xf0
  el0t_64_sync+0x198/0x19c

The __devm_regmap_init_slimbus() started to be used instead of
__regmap_init_slimbus() after the commit mentioned above and turns out
the incorrect bus_context pointer (3rd argument) was used in
__devm_regmap_init_slimbus(). It should be just "slimbus" (which is equal
to &slimbus->dev). Correct it. The wcd934x codec seems to be the only or
the first user of devm_regmap_init_slimbus() but we should fix it till
the point where __devm_regmap_init_slimbus() was introduced therefore
two "Fixes" tags.

While at this, also correct the same argument in __regmap_init_slimbus().
References: https://git.kernel.org/stable/c/02d3041caaa3fe4dd69e5a8afd1ac6b918ddc6a1; https://git.kernel.org/stable/c/2664bfd8969d1c43dcbe3ea313f130dfa6b74f4c; https://git.kernel.org/stable/c/434f7349a1f00618a620b316f091bd13a12bc8d2
CVE: CVE-2025-40318
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_once

hci_cmd_sync_dequeue_once() does lookup and then cancel
the entry under two separate lock sections. Meanwhile,
hci_cmd_sync_work() can also delete the same entry,
leading to double list_del() and "UAF".

Fix this by holding cmd_sync_work_lock across both
lookup and cancel, so that the entry cannot be removed
concurrently.
References: https://git.kernel.org/stable/c/09b0cd1297b4dbfe736aeaa0ceeab2265f47f772; https://git.kernel.org/stable/c/0a94f7e017438935c09ef833a1aa908ad9875213; https://git.kernel.org/stable/c/932c0a4f77ac13e526fdd5b42914d29c9821d389
CVE: CVE-2025-40319
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Sync pending IRQ work before freeing ring buffer

Fix a race where irq_work can be queued in bpf_ringbuf_commit()
but the ring buffer is freed before the work executes.
In the syzbot reproducer, a BPF program attached to sched_switch
triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer
is freed before this work executes, the irq_work thread may accesses
freed memory.
Calling `irq_work_sync(&rb->work)` ensures that all pending irq_work
complete before freeing the buffer.
References: https://git.kernel.org/stable/c/10ca3b2eec384628bc9f5d8190aed9427ad2dde6; https://git.kernel.org/stable/c/430e15544f11f8de26b2b5109c7152f71b78295e; https://git.kernel.org/stable/c/47626748a2a00068dbbd5836d19076637b4e235b
CVE: CVE-2025-40320
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix potential cfid UAF in smb2_query_info_compound

When smb2_query_info_compound() retries, a previously allocated cfid may
have been freed in the first attempt.
Because cfid wasn't reset on replay, later cleanup could act on a stale
pointer, leading to a potential use-after-free.

Reinitialize cfid to NULL under the replay label.

Example trace (trimmed):

refcount_t: underflow; use-after-free.
WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110
[...]
RIP: 0010:refcount_warn_saturate+0x9c/0x110
[...]
Call Trace:
 <TASK>
 smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]
 ? step_into+0x10d/0x690
 ? __legitimize_path+0x28/0x60
 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]
 smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]
 ? kmem_cache_alloc+0x18a/0x340
 ? getname_flags+0x46/0x1e0
 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]
 statfs_by_dentry+0x67/0x90
 vfs_statfs+0x16/0xd0
 user_statfs+0x54/0xa0
 __do_sys_statfs+0x20/0x50
 do_syscall_64+0x58/0x80
References: https://git.kernel.org/stable/c/327f89c21601ebb7889f8c97754b76f08ce95a0c; https://git.kernel.org/stable/c/5c76f9961c170552c1d07c830b5e[PII_REDACTED]0; https://git.kernel.org/stable/c/939c4e33005e2a56ea8fcedddf0da92df864bd3b
CVE: CVE-2025-40321
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: fix crash while sending Action Frames in standalone AP Mode

Currently, whenever there is a need to transmit an Action frame,
the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR to
firmware. The P2P interfaces were available when wpa_supplicant is managing
the wlan interface.

However, the P2P interfaces are not created/initialized when only hostapd
is managing the wlan interface. And if hostapd receives an ANQP Query REQ
Action frame even from an un-associated STA, the brcmfmac driver tries
to use an uninitialized P2P vif pointer for sending the IOVAR to firmware.
This NULL pointer dereferencing triggers a driver crash.

 [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual
 address [PII_REDACTED]
 [...]
 [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT)
 [...]
 [ 1417.075653] Call trace:
 [ 1417.075662]  brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac]
 [ 1417.075738]  brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac]
 [ 1417.075810]  cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211]
 [ 1417.076067]  nl80211_tx_mgmt+0x238/0x388 [cfg80211]
 [ 1417.076281]  genl_family_rcv_msg_doit+0xe0/0x158
 [ 1417.076302]  genl_rcv_msg+0x220/0x2a0
 [ 1417.076317]  netlink_rcv_skb+0x68/0x140
 [ 1417.076330]  genl_rcv+0x40/0x60
 [ 1417.076343]  netlink_unicast+0x330/0x3b8
 [ 1417.076357]  netlink_sendmsg+0x19c/0x3f8
 [ 1417.076370]  __sock_sendmsg+0x64/0xc0
 [ 1417.076391]  ____sys_sendmsg+0x268/0x2a0
 [ 1417.076408]  ___sys_sendmsg+0xb8/0x118
 [ 1417.076427]  __sys_sendmsg+0x90/0xf8
 [ 1417.076445]  __arm64_sys_sendmsg+0x2c/0x40
 [ 1417.076465]  invoke_syscall+0x50/0x120
 [ 1417.076486]  el0_svc_common.constprop.0+0x48/0xf0
 [ 1417.076506]  do_el0_svc+0x24/0x38
 [ 1417.076525]  el0_svc+0x30/0x100
 [ 1417.076548]  el0t_64_sync_handler+0x100/0x130
 [ 1417.076569]  el0t_64_sync+0x190/0x198
 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)

Fix this, by always using the vif corresponding to the wdev on which the
Action frame Transmission request was initiated by the userspace. This way,
even if P2P vif is not available, the IOVAR is sent to firmware on AP vif
and the ANQP Query RESP Action frame is transmitted without crashing the
driver.

Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()
to brcmf_p2p_attach(). Because the former function would not get executed
when only hostapd is managing wlan interface, and it is not safe to do
reinit_completion() later in brcmf_p2p_tx_action_frame(), without any prior
init_completion().

And in the brcmf_p2p_tx_action_frame() function, the condition check for
P2P Presence response frame is not needed, since the wpa_supplicant is
properly sending the P2P Presense Response frame on the P2P-GO vif instead
of the P2P-Device vif.

[Cc stable]
References: https://git.kernel.org/stable/c/3776c685ebe5f43e9060af06872661de55e80b9a; https://git.kernel.org/stable/c/55f60a72a178909ece4e32987e4c642ba57e1cf4; https://git.kernel.org/stable/c/64e3175d1c8a3bea02032e7c9d1befd5f43786fa
CVE: CVE-2025-40322
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: bitblit: bound-check glyph index in bit_putcs*

bit_putcs_aligned()/unaligned() derived the glyph pointer from the
character value masked by 0xff/0x1ff, which may exceed the actual font's
glyph count and read past the end of the built-in font array.
Clamp the index to the actual glyph count before computing the address.

This fixes a global out-of-bounds read reported by syzbot.
References: https://git.kernel.org/stable/c/0998a6cb232674408a03e8561dc15aa266b2f53b; https://git.kernel.org/stable/c/18c4ef4e765a798b47980555ed665d78b71aeadf; https://git.kernel.org/stable/c/901f44227072be60812fe8083e83e1533c04eed1
CVE: CVE-2025-40323
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

fbcon: Set fb_display[i]->mode to NULL when the mode is released

Recently, we discovered the following issue through syzkaller:

BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0
Read of size 4 at addr ff11000001b3c69c by task syz.xxx
...
Call Trace:
 <TASK>
 dump_stack_lvl+0xab/0xe0
 print_address_description.constprop.0+0x2c/0x390
 print_report+0xb9/0x280
 kasan_report+0xb8/0xf0
 fb_mode_is_equal+0x285/0x2f0
 fbcon_mode_deleted+0x129/0x180
 fb_set_var+0xe7f/0x11d0
 do_fb_ioctl+0x6a0/0x750
 fb_ioctl+0xe0/0x140
 __x64_sys_ioctl+0x193/0x210
 do_syscall_64+0x5f/0x9c0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Based on experimentation and analysis, during framebuffer unregistration,
only the memory of fb_info->modelist is freed, without setting the
corresponding fb_display[i]->mode to NULL for the freed modes. This leads
to UAF issues during subsequent accesses. Here's an example of reproduction
steps:
1. With /dev/fb0 already registered in the system, load a kernel module
   to register a new device /dev/fb1;
2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);
3. Switch console from fb to VGA (to allow normal rmmod of the ko);
4. Unload the kernel module, at this point fb1's modelist is freed, leaving
   a wild pointer in fb_display[];
5. Trigger the bug via system calls through fb0 attempting to delete a mode
   from fb0.

Add a check in do_unregister_framebuffer(): if the mode to be freed exists
in fb_display[], set the corresponding mode pointer to NULL.
References: https://git.kernel.org/stable/c/39c2c1a2773aaf73e56906e5ef670114eb2d354f; https://git.kernel.org/stable/c/468f78276a37f4c6499385a4ce28f4f57be6655d; https://git.kernel.org/stable/c/4ac18f0e6a6d599ca751c4cd98e522afc8e3d4eb
CVE: CVE-2025-40324
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix crash in nfsd4_read_release()

When tracing is enabled, the trace_nfsd_read_done trace point
crashes during the pynfs read.testNoFh test.
References: https://git.kernel.org/stable/c/03524ccff698d4a77d096ed529073d91f5edee5d; https://git.kernel.org/stable/c/2ac46606b2cc49e78d8e3d8f2685e79e9ba73020; https://git.kernel.org/stable/c/375fdd8993cecc48afa359728a6e70b280dde1c8
CVE: CVE-2025-40326
Published: 2025-12-08
Description: In the Linux kernel, the following vulnerability has been resolved:

NFSD: Define actions for the new time_deleg FATTR4 attributes

NFSv4 clients won't send legitimate GETATTR requests for these new
attributes because they are intended to be used only with CB_GETATTR
and SETATTR. But NFSD has to do something besides crashing if it
ever sees a GETATTR request that queries these attributes.

RFC 8881 Section 18.7.3 states:

> The server MUST return a value for each attribute that the client
> requests if the attribute is supported by the server for the
> target file system. If the server does not support a particular
> attribute on the target file system, then it MUST NOT return the
> attribute value and MUST NOT set the attribute bit in the result
> bitmap. The server MUST return an error if it supports an
> attribute on the target but cannot obtain its value. In that case,
> no attribute values will be returned.

Further, RFC 9754 Section 5 states:

> These new attributes are invalid to be used with GETATTR, VERIFY,
> and NVERIFY, and they can only be used with CB_GETATTR and SETATTR
> by a client holding an appropriate delegation.

Thus there does not appear to be a specific server response mandated
by specification. Taking the guidance that querying these attributes
via GETATTR is "invalid", NFSD will return nfserr_inval, failing the
request entirely.
References: https://git.kernel.org/stable/c/4f76435fd517981f01608678c06ad9718a86ee98; https://git.kernel.org/stable/c/d8f3f94dc950e7c62c96af432c26745885b0a18a