deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38683
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

hv_netvsc: Fix panic during namespace deletion with VF

The existing code move the VF NIC to new namespace when NETDEV_REGISTER is
received on netvsc NIC. During deletion of the namespace,
default_device_exit_batch() >> default_device_exit_net() is called. When
netvsc NIC is moved back and registered to the default namespace, it
automatically brings VF NIC back to the default namespace. This will cause
the default_device_exit_net() >> for_each_netdev_safe loop unable to detect
the list end, and hit NULL ptr:

[  231.449420] mana 7870:00:00.0 enP30832s1: Moved VF to namespace with: eth0
[  231.449656] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[  231.450246] #PF: supervisor read access in kernel mode
[  231.450579] #PF: error_code(0x0000) - not-present page
[  231.450916] PGD 17b8a8067 P4D 0
[  231.451163] Oops: Oops: 0000 [#1] SMP NOPTI
[  231.451450] CPU: 82 UID: 0 PID: 1394 Comm: kworker/u768:1 Not tainted 6.16.0-rc4+ #3 VOLUNTARY
[  231.452042] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024
[  231.452692] Workqueue: netns cleanup_net
[  231.452947] RIP: 0010:default_device_exit_batch+0x16c/0x3f0
[  231.453326] Code: c0 0c f5 b3 e8 d5 db fe ff 48 85 c0 74 15 48 c7 c2 f8 fd ca b2 be 10 00 00 00 48 8d 7d c0 e8 7b 77 25 00 49 8b 86 28 01 00 00 <48> 8b 50 10 4c 8b 2a 4c 8d 62 f0 49 83 ed 10 4c 39 e0 0f 84 d6 00
[  231.454294] RSP: 0018:ff75fc7c9bf9fd00 EFLAGS: 00010246
[  231.454610] RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: 61c8864680b583eb
[  231.455094] RDX: ff1fa9f71462d800 RSI: ff75fc7c9bf9fd38 RDI: [PII_REDACTED]
[  231.455686] RBP: ff75fc7c9bf9fd78 R08: [PII_REDACTED] R09: [PII_REDACTED]
[  231.456126] R10: [PII_REDACTED] R11: [PII_REDACTED] R12: ff1fa9f70088e340
[  231.456621] R13: ff1fa9f70088e340 R14: ffffffffb3f50c20 R15: ff1fa9f7103e6340
[  231.457161] FS:  [PII_REDACTED](0000) GS:ff1faa6783a08000(0000) knlGS:[PII_REDACTED]
[  231.457707] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[  231.458031] CR2: [PII_REDACTED] CR3:[PII_REDACTED]ab2006 CR4:[PII_REDACTED]b73ef0
[  231.458434] Call Trace:
[  231.458600]  <TASK>
[  231.458777]  ops_undo_list+0x100/0x220
[  231.459015]  cleanup_net+0x1b8/0x300
[  231.459285]  process_one_work+0x184/0x340

To fix it, move the ns change to a workqueue, and take rtnl_lock to avoid
changing the netdev list when default_device_exit_net() is using it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2a70cbd1aef8b8be39992ab7b776ce[PII_REDACTED]; https://git.kernel.org/stable/c/33caa208dba6fa639e8a92fd0c8320b652e5550c; https://git.kernel.org/stable/c/3467c4ebb334658c6fcf3eabb64a6e8b2135e010
CVE: CVE-2025-38685
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: Fix vmalloc out-of-bounds write in fast_imageblit

This issue triggers when a userspace program does an ioctl
FBIOPUT_CON2FBMAP by passing console number and frame buffer number.
Ideally this maps console to frame buffer and updates the screen if
console is visible.

As part of mapping it has to do resize of console according to frame
buffer info. if this resize fails and returns from vc_do_resize() and
continues further. At this point console and new frame buffer are mapped
and sets display vars. Despite failure still it continue to proceed
updating the screen at later stages where vc_data is related to previous
frame buffer and frame buffer info and display vars are mapped to new
frame buffer and eventully leading to out-of-bounds write in
fast_imageblit(). This bheviour is excepted only when fg_console is
equal to requested console which is a visible console and updates screen
with invalid struct references in fbcon_putcs().
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/078e62bffca4b7e72e8f3550eb063ab981c36c7a; https://git.kernel.org/stable/c/27b118aebdd84161c8ff5ce49d9d536f2af10754; https://git.kernel.org/stable/c/4c4d7ddaf1d43780b106bedc692679f965dc5a3a
CVE: CVE-2025-38686
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

userfaultfd: fix a crash in UFFDIO_MOVE when PMD is a migration entry

When UFFDIO_MOVE encounters a migration PMD entry, it proceeds with
obtaining a folio and accessing it even though the entry is swp_entry_t. 
Add the missing check and let split_huge_pmd() handle migration entries. 
While at it also remove unnecessary folio check.

[surenb@google.com: remove extra folio check, per David]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1202abad7a7ccd28c426d2844771a387b07629a4; https://git.kernel.org/stable/c/7f1101a0a181243ad587ececdffc4845f035549f; https://git.kernel.org/stable/c/aba6faec0103ed8f169be8dce2ead41fcb689446
CVE: CVE-2025-38687
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

comedi: fix race between polling and detaching

syzbot reports a use-after-free in comedi in the below link, which is
due to comedi gladly removing the allocated async area even though poll
requests are still active on the wait_queue_head inside of it. This can
cause a use-after-free when the poll entries are later triggered or
removed, as the memory for the wait_queue_head has been freed.  We need
to check there are no tasks queued on any of the subdevices' wait queues
before allowing the device to be detached by the `COMEDI_DEVCONFIG`
ioctl.

Tasks will read-lock `dev->attach_lock` before adding themselves to the
subdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctl
handler by write-locking `dev->attach_lock` before checking that all of
the subdevices are safe to be deleted.  This includes testing for any
sleepers on the subdevices' wait queues.  It remains locked until the
device has been detached.  This requires the `comedi_device_detach()`
function to be refactored slightly, moving the bulk of it into new
function `comedi_device_detach_locked()`.

Note that the refactor of `comedi_device_detach()` results in
`comedi_device_cancel_all()` now being called while `dev->attach_lock`
is write-locked, which wasn't the case previously, but that does not
matter.

Thanks to Jens Axboe for diagnosing the problem and co-developing this
patch.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/[PII_REDACTED]51a2a5cf61eae966af3c4b145e1f3b; https://git.kernel.org/stable/c/0f989f9d05492028afd2bded4b42023c57d8a76e; https://git.kernel.org/stable/c/35b6fc51c666fc96355be5cd633ed0fe4ccf68b2
CVE: CVE-2025-38688
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

iommufd: Prevent ALIGN() overflow

When allocating IOVA the candidate range gets aligned to the target
alignment. If the range is close to ULONG_MAX then the ALIGN() can
wrap resulting in a corrupted iova.

Open code the ALIGN() using get_add_overflow() to prevent this.
This simplifies the checks as we don't need to check for length earlier
either.

Consolidate the two copies of this code under a single helper.

This bug would allow userspace to create a mapping that overlaps with some
other mapping or a reserved range.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/79fad1917802c28de51a479318a056a6fbe3e2f2; https://git.kernel.org/stable/c/b42497e3c0e74db061eafad41c0cd7243c46436b; https://git.kernel.org/stable/c/d19b817540c0abe84854a64ee9ee34cecc3bbeef
CVE: CVE-2025-38689
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/fpu: Fix NULL dereference in avx512_status()

Problem
-------
With CONFIG_X86_DEBUG_FPU enabled, reading /proc/[kthread]/arch_status
causes a warning and a NULL pointer dereference.

This is because the AVX-512 timestamp code uses x86_task_fpu() but
doesn't check it for NULL. CONFIG_X86_DEBUG_FPU addles that function
for kernel threads (PF_KTHREAD specifically), making it return NULL.

The point of the warning was to ensure that kernel threads only access
task->fpu after going through kernel_fpu_begin()/_end(). Note: all
kernel tasks exposed in /proc have a valid task->fpu.

Solution
--------
One option is to silence the warning and check for NULL from
x86_task_fpu(). However, that warning is fairly fresh and seems like a
defense against misuse of the FPU state in kernel threads.

Instead, stop outputting AVX-512_elapsed_ms for kernel threads
altogether. The data was garbage anyway because avx512_timestamp is
only updated for user threads, not kernel threads.

If anyone ever wants to track kernel thread AVX-512 use, they can come
back later and do it properly, separate from this bug fix.

[ dhansen: mostly rewrite changelog ]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2ca887e81095b99d890a8878841f36f4920181e6; https://git.kernel.org/stable/c/31cd31c9e17ece125aad27259501a2af69ccb020
CVE: CVE-2025-38690
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/migrate: prevent infinite recursion

If the buf + offset is not aligned to XE_CAHELINE_BYTES we fallback to
using a bounce buffer. However the bounce buffer here is allocated on
the stack, and the only alignment requirement here is that it's
naturally aligned to u8, and not XE_CACHELINE_BYTES. If the bounce
buffer is also misaligned we then recurse back into the function again,
however the new bounce buffer might also not be aligned, and might never
be until we eventually blow through the stack, as we keep recursing.

Instead of using the stack use kmalloc, which should respect the
power-of-two alignment request here. Fixes a kernel panic when
triggering this path through eudebug.

v2 (Stuart):
 - Add build bug check for power-of-two restriction
 - s/EINVAL/ENOMEM/

(cherry picked from commit 38b34e928a08ba594c4bbf7118aa3aadacd62fff)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/89f511c024879c5812cc0c010a6663b5e49950f3; https://git.kernel.org/stable/c/9d7a1cbebbb691891671def57407ba2f8ee914e8
CVE: CVE-2025-38691
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

pNFS: Fix uninited ptr deref in block/scsi layout

The error occurs on the third attempt to encode extents. When function
ext_tree_prepare_commit() reallocates a larger buffer to retry encoding
extents, the "layoutupdate_pages" page array is initialized only after the
retry loop. But ext_tree_free_commitdata() is called on every iteration
and tries to put pages in the array, thus dereferencing uninitialized
pointers.

An additional problem is that there is no limit on the maximum possible
buffer_size. When there are too many extents, the client may create a
layoutcommit that is larger than the maximum possible RPC size accepted
by the server.

During testing, we observed two typical scenarios. First, one memory page
for extents is enough when we work with small files, append data to the
end of the file, or preallocate extents before writing. But when we fill
a new large file without preallocating, the number of extents can be huge,
and counting the number of written extents in ext_tree_encode_commit()
does not help much. Since this number increases even more between
unlocking and locking of ext_tree, the reallocated buffer may not be
large enough again and again.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/24334f3cf8a294f253071b5bf22d754dbb6d0f2d; https://git.kernel.org/stable/c/2896f101110076ac6bf99d7aaf463d61e26f89dd; https://git.kernel.org/stable/c/37c3443a2685528f972d910a6fb87716b96fef46
CVE: CVE-2025-38692
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

exfat: add cluster chain loop check for dir

An infinite loop may occur if the following conditions occur due to
file system corruption.

(1) Condition for exfat_count_dir_entries() to loop infinitely.
    - The cluster chain includes a loop.
    - There is no UNUSED entry in the cluster chain.

(2) Condition for exfat_create_upcase_table() to loop infinitely.
    - The cluster chain of the root directory includes a loop.
    - There are no UNUSED entry and up-case table entry in the cluster
      chain of the root directory.

(3) Condition for exfat_load_bitmap() to loop infinitely.
    - The cluster chain of the root directory includes a loop.
    - There are no UNUSED entry and bitmap entry in the cluster chain
      of the root directory.

(4) Condition for exfat_find_dir_entry() to loop infinitely.
    - The cluster chain includes a loop.
    - The unused directory entries were exhausted by some operation.

(5) Condition for exfat_check_dir_empty() to loop infinitely.
    - The cluster chain includes a loop.
    - The unused directory entries were exhausted by some operation.
    - All files and sub-directories under the directory are deleted.

This commit adds checks to break the above infinite loop.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/4c3cda20c4cf1871e27868d08fda06b79bc7d568; https://git.kernel.org/stable/c/868f23286c1a13162330fa6c614fe350f78e3f82; https://git.kernel.org/stable/c/99f9a97dce39ad413c39b92c90393bbd6778f3fd
CVE: CVE-2025-38693
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serpar

In w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We add
check on msg[0].len to prevent crash.

Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/17b30e5ded062bd74f8ca6f317e1d415a8680665; https://git.kernel.org/stable/c/39b06b93f24dff923c4183d564ed28c039150554; https://git.kernel.org/stable/c/454a443eaa792c8865c861a282fe6d4f596abc3a
CVE: CVE-2025-38694
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

media: dvb-frontends: dib7090p: fix null-ptr-deref in dib7090p_rw_on_apb()

In dib7090p_rw_on_apb, msg is controlled by user. When msg[0].buf is null and
msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing
msg[0].buf[2] without sanity check, null pointer deref would happen. We add
check on msg[0].len to prevent crash. Similar issue occurs when access
msg[1].buf[0] and msg[1].buf[1].

Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/[PII_REDACTED]4a09b3a4d4b3d[PII_REDACTED]810becd; https://git.kernel.org/stable/c/0bb32863426afe0badac25c28d59021f211d0f48; https://git.kernel.org/stable/c/19eb5d8e6aa1169d368a4d69aae5572950deb89d
CVE: CVE-2025-38695
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structure

If a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, the
resultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() may
occur before sli4_hba.hdwqs are allocated.  This may result in a null
pointer dereference when attempting to take the abts_io_buf_list_lock for
the first hardware queue.  Fix by adding a null ptr check on
phba->sli4_hba.hdwq and early return because this situation means there
must have been an error during port initialization.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/46a0602c24d7d425dd8e00c749cd64a934aac7ec; https://git.kernel.org/stable/c/571617f171f723b05f02d154a2e549a17eab4935; https://git.kernel.org/stable/c/5e25ee1ecec91c61a8acf938ad338399cad464de
CVE: CVE-2025-38696
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

MIPS: Don't crash in stack_top() for tasks without ABI or vDSO

Not all tasks have an ABI associated or vDSO mapped,
for example kthreads never do.
If such a task ever ends up calling stack_top(), it will derefence the
NULL ABI pointer and crash.

This can for example happen when using kunit:

    mips_stack_top+0x28/0xc0
    arch_pick_mmap_layout+0x190/0x220
    kunit_vm_mmap_init+0xf8/0x138
    __kunit_add_resource+0x40/0xa8
    kunit_vm_mmap+0x88/0xd8
    usercopy_test_init+0xb8/0x240
    kunit_try_run_case+0x5c/0x1a8
    kunit_generic_run_threadfn_adapter+0x28/0x50
    kthread+0x118/0x240
    ret_from_kernel_thread+0x14/0x1c

Only dereference the ABI point if it is set.

The GIC page is also included as it is specific to the vDSO.
Also move the randomization adjustment into the same conditional.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/24d098b6f69b0aa806ffcb3e18259bee31650b28; https://git.kernel.org/stable/c/5b6839b572b503609b9b58bc6c04a816eefa0794; https://git.kernel.org/stable/c/82d140f6aab5e89a9d3972697a0dbe1498752d9b
CVE: CVE-2025-38697
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: upper bound check of tree index in dbAllocAG

When computing the tree index in dbAllocAG, we never check if we are
out of bounds realative to the size of the stree.
This could happen in a scenario where the filesystem metadata are
corrupted.
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/1467a75819e41341cd5ebd16faa2af1ca3c8f4fe; https://git.kernel.org/stable/c/173cfd741ad7073640bfb7e2344c2a0ee005e769; https://git.kernel.org/stable/c/2dd05f09cc323018136a7ecdb3d1007be9ede27f
CVE: CVE-2025-38698
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

jfs: Regular file corruption check

The reproducer builds a corrupted file on disk with a negative i_size value.
Add a check when opening this file to avoid subsequent operation failures.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/00462be586b33076f8b8023e7ba697deedc131db; https://git.kernel.org/stable/c/02edcfda419168d9405bffe55f18ea9c1bf92366; https://git.kernel.org/stable/c/2d04df8116426b6c7b9f8b9b371250f666a2a2fb
CVE: CVE-2025-38699
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: bfa: Double-free fix

When the bfad_im_probe() function fails during initialization, the memory
pointed to by bfad->im is freed without setting bfad->im to NULL.

Subsequently, during driver uninstallation, when the state machine enters
the bfad_sm_stopping state and calls the bfad_im_probe_undo() function,
it attempts to free the memory pointed to by bfad->im again, thereby
triggering a double-free vulnerability.

Set bfad->im to NULL if probing fails.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/13f613228cf3c96a038424cd97aa4d6aadc66294; https://git.kernel.org/stable/c/39cfe2c83146aad956318f866d0ee471b7a61fa5; https://git.kernel.org/stable/c/50d9bd48321038bd6e15af5a454bbcd180cf6f80
CVE: CVE-2025-38700
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocated

In case of an ib_fast_reg_mr allocation failure during iSER setup, the
machine hits a panic because iscsi_conn->dd_data is initialized
unconditionally, even when no memory is allocated (dd_size == 0).  This
leads invalid pointer dereference during connection teardown.

Fix by setting iscsi_conn->dd_data only if memory is actually allocated.

Panic trace:
------------
 iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12
 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers
 BUG: unable to handle page fault for address: fffffffffffffff8
 RIP: 0010:swake_up_locked.part.5+0xa/0x40
 Call Trace:
  complete+0x31/0x40
  iscsi_iser_conn_stop+0x88/0xb0 [ib_iser]
  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]
  iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi]
  iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi]
  ? netlink_lookup+0x12f/0x1b0
  ? netlink_deliver_tap+0x2c/0x200
  netlink_unicast+0x1ab/0x280
  netlink_sendmsg+0x257/0x4f0
  ? _copy_from_user+0x29/0x60
  sock_sendmsg+0x5f/0x70
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2b242ea14386a510010eabfbfc3ce81a101f3802; https://git.kernel.org/stable/c/35782c32528d82aa21f84cb5ceb2abd3526a8159; https://git.kernel.org/stable/c/3ea3a256ed81f95ab0f3281a0e234b01a9cae605
CVE: CVE-2025-38701
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: do not BUG when INLINE_DATA_FL lacks system.data xattr

A syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()
when an inode had the INLINE_DATA_FL flag set but was missing the
system.data extended attribute.

Since this can happen due to a maiciouly fuzzed file system, we
shouldn't BUG, but rather, report it as a corrupted file system.

Add similar replacements of BUG_ON with EXT4_ERROR_INODE() ii
ext4_create_inline_data() and ext4_inline_data_truncate().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/099b847ccc6c1ad2f805d13cfbcc83f5b6d4bc42; https://git.kernel.org/stable/c/1199a6399895f4767f0b9a68a6ff47c3f799b7c7; https://git.kernel.org/stable/c/279c87ef7b9da34f65c2e4db586e730b667a6fb9
CVE: CVE-2025-38702
Published: 2025-09-04
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: fix potential buffer overflow in do_register_framebuffer()

The current implementation may lead to buffer overflow when:
1.  Unregistration creates NULL gaps in registered_fb[]
2.  All array slots become occupied despite num_registered_fb < FB_MAX
3.  The registration loop exceeds array bounds

Add boundary check to prevent registered_fb[FB_MAX] access.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/248b2aab9b2af5ecf89d9d7955a2ff20c4b4a399; https://git.kernel.org/stable/c/2828a433c7d7a05b6f27c[PII_REDACTED]101dd0b09; https://git.kernel.org/stable/c/523b84dc7ccea9c4d79126d6ed1cf9033cf83b05
CVE: CVE-2025-38703
Published: 2025-09-04
Description: 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.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/683b0e397dad9f26a42dcacf6f7f545a77ce6c06; https://git.kernel.org/stable/c/6bd90e700b4285e6a7541e00f969cab0d696adde; https://git.kernel.org/stable/c/b17fcce70733c211cb5dabf54f4f9491920b1d92