deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-40056
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

vhost: vringh: Fix copy_to_iter return value check

The return value of copy_to_iter can't be negative, check whether the
copied length is equal to the requested length instead of checking for
negative values.
References: https://git.kernel.org/stable/c/439263376c2c4e126cac0d07e4987568de4eaba5; https://git.kernel.org/stable/c/68aac2b335d474b938d154b9c95cbc58838cb2ce; https://git.kernel.org/stable/c/781226e11d5bdea0d69c7b5aa3cda874093c73b8
CVE: CVE-2025-40057
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: Add a upper bound on max_vclocks

syzbot reported WARNING in max_vclocks_store.

This occurs when the argument max is too large for kcalloc to handle.

Extend the guard to guard against values that are too large for
kcalloc
References: https://git.kernel.org/stable/c/35ce5f163889dbce88eda1df661b357a09bbed87; https://git.kernel.org/stable/c/8dd446056336faa2283d62cefc2f576536845edc; https://git.kernel.org/stable/c/e9f35294e18da82162004a2f35976e7031aaf7f9
CVE: CVE-2025-40058
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Disallow dirty tracking if incoherent page walk

Dirty page tracking relies on the IOMMU atomically updating the dirty bit
in the paging-structure entry. For this operation to succeed, the paging-
structure memory must be coherent between the IOMMU and the CPU. In
another word, if the iommu page walk is incoherent, dirty page tracking
doesn't work.

The Intel VT-d specification, Section 3.10 "Snoop Behavior" states:

"Remapping hardware encountering the need to atomically update A/EA/D bits
 in a paging-structure entry that is not snooped will result in a non-
 recoverable fault."

To prevent an IOMMU from being incorrectly configured for dirty page
tracking when it is operating in an incoherent mode, mark SSADS as
supported only when both ecap_slads and ecap_smpwc are supported.
References: https://git.kernel.org/stable/c/57f55048e564dedd8a4546d018e29d6bbfff0a7e; https://git.kernel.org/stable/c/8d096ce0e87bdc361f0b25d7943543bc53aa0b9e; https://git.kernel.org/stable/c/ebe16d245a00626bb87163862a1b07daf5475a3e
CVE: CVE-2025-40059
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

coresight: Fix incorrect handling for return value of devm_kzalloc

The return value of devm_kzalloc could be an null pointer,
use "!desc.pdata" to fix incorrect handling return value
of devm_kzalloc.
References: https://git.kernel.org/stable/c/70714eb7243eaf333d23501d4c7bdd9daf011c01; https://git.kernel.org/stable/c/8c4e7e646d5d9050b374baf5c6bb3a00fb79e206; https://git.kernel.org/stable/c/9688b66d0a5e0eecf44f6286b8d9f7a161264035
CVE: CVE-2025-40060
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

coresight: trbe: Return NULL pointer for allocation failures

When the TRBE driver fails to allocate a buffer, it currently returns
the error code "-ENOMEM". However, the caller etm_setup_aux() only
checks for a NULL pointer, so it misses the error. As a result, the
driver continues and eventually causes a kernel panic.

Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() on
allocation failures. This allows that the callers can properly handle
the failure.
References: https://git.kernel.org/stable/c/296da78494633e1ab5e2e74173a9c8683b04aa6b; https://git.kernel.org/stable/c/8a55c161f7f9c1aa1c70611b39830d51c83ef36d; https://git.kernel.org/stable/c/9768536f82600a05ce901e31ccfabd92c027ff71
CVE: CVE-2025-40061
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix race in do_task() when draining

When do_task() exhausts its iteration budget (!ret), it sets the state
to TASK_STATE_IDLE to reschedule, without a secondary check on the
current task->state. This can overwrite the TASK_STATE_DRAINING state
set by a concurrent call to rxe_cleanup_task() or rxe_disable_task().

While state changes are protected by a spinlock, both rxe_cleanup_task()
and rxe_disable_task() release the lock while waiting for the task to
finish draining in the while(!is_done(task)) loop. The race occurs if
do_task() hits its iteration limit and acquires the lock in this window.
The cleanup logic may then proceed while the task incorrectly
reschedules itself, leading to a potential use-after-free.

This bug was introduced during the migration from tasklets to workqueues,
where the special handling for the draining case was lost.

Fix this by restoring the original pre-migration behavior. If the state is
TASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to
force a new loop iteration. This allows the task to finish its work, so
that a subsequent iteration can reach the switch statement and correctly
transition the state to TASK_STATE_DRAINED, stopping the task as intended.
References: https://git.kernel.org/stable/c/52edccfb555142678c836c285bf5b4ec760bd043; https://git.kernel.org/stable/c/660b6959c4170637f5db2279d1f71af33a49e49b; https://git.kernel.org/stable/c/85288bcf7ffe11e7b036edf91937bc62fd384076
CVE: CVE-2025-40062
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: hisilicon/qm - set NULL to qm->debug.qm_diff_regs

When the initialization of qm->debug.acc_diff_reg fails,
the probe process does not exit. However, after qm->debug.qm_diff_regs is
freed, it is not set to NULL. This can lead to a double free when the
remove process attempts to free it again. Therefore, qm->debug.qm_diff_regs
should be set to NULL after it is freed.
References: https://git.kernel.org/stable/c/1750f1ec143ebabdbdfa013668665c9d5042c430; https://git.kernel.org/stable/c/7226a0650ad5705bd8d39a11be270fa21ed1e6a5; https://git.kernel.org/stable/c/a7836260d5121949ba734e840d42a86ab4a32fcc
CVE: CVE-2025-40063
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: comp - Use same definition of context alloc and free ops

In commit 42d9f6c77479 ("crypto: acomp - Move scomp stream allocation
code into acomp"), the crypto_acomp_streams struct was made to rely on
having the alloc_ctx and free_ctx operations defined in the same order
as the scomp_alg struct. But in that same commit, the alloc_ctx and
free_ctx members of scomp_alg may be randomized by structure layout
randomization, since they are contained in a pure ops structure
(containing only function pointers). If the pointers within scomp_alg
are randomized, but those in crypto_acomp_streams are not, then
the order may no longer match. This fixes the problem by removing the
union from scomp_alg so that both crypto_acomp_streams and scomp_alg
will share the same definition of alloc_ctx and free_ctx, ensuring
they will always have the same layout.
References: https://git.kernel.org/stable/c/779d3b6f2d32c5f1da6163e959abe1e1ffe2945b; https://git.kernel.org/stable/c/f75f66683ded09f7135aef2e763c245a07c8271a
CVE: CVE-2025-40065
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

RISC-V: KVM: Write hgatp register with valid mode bits

According to the RISC-V Privileged Architecture Spec, when MODE=Bare
is selected,software must write zero to the remaining fields of hgatp.

We have detected the valid mode supported by the HW before, So using a
valid mode to detect how many vmid bits are supported.
References: https://git.kernel.org/stable/c/2b351e3d04be9e1533f26c3464f1e44a5beace30; https://git.kernel.org/stable/c/d00b61cd37f4c183ce0edbc9f8ccf6d5430ea357
CVE: CVE-2025-40066
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: Check phy before init msta_link in mt7996_mac_sta_add_links()

In order to avoid a possible NULL pointer dereference in
mt7996_mac_sta_init_link routine, move the phy pointer check before
running mt7996_mac_sta_init_link() in mt7996_mac_sta_add_links routine.
References: https://git.kernel.org/stable/c/2e671536c1c3c7bcad95d408a4ab42e2e54d1882; https://git.kernel.org/stable/c/fe5fffadc6c77c56f122cf1042dc830f59e904bf
CVE: CVE-2025-40067
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: reject index allocation if $BITMAP is empty but blocks exist

Index allocation requires at least one bit in the $BITMAP attribute to
track usage of index entries. If the bitmap is empty while index blocks
are already present, this reflects on-disk corruption.

syzbot triggered this condition using a malformed NTFS image. During a
rename() operation involving a long filename (which spans multiple
index entries), the empty bitmap allowed the name to be added without
valid tracking. Subsequent deletion of the original entry failed with
-ENOENT, due to unexpected index state.

Reject such cases by verifying that the bitmap is not empty when index
blocks exist.
References: https://git.kernel.org/stable/c/039ddf353cc33f6546a87ec1ac3210637d714bec; https://git.kernel.org/stable/c/0dc7117da8f92dd5fe077d712a756eccbe377d40; https://git.kernel.org/stable/c/978aac54e93ea35aab20b32ae393d3d33964e7ae
CVE: CVE-2025-40068
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

fs: ntfs3: Fix integer overflow in run_unpack()

The MFT record relative to the file being opened contains its runlist,
an array containing information about the file's location on the physical
disk. Analysis of all Call Stack paths showed that the values of the
runlist array, from which LCNs are calculated, are not validated before
run_unpack function.

The run_unpack function decodes the compressed runlist data format
from MFT attributes (for example, $DATA), converting them into a runs_tree
structure, which describes the mapping of virtual clusters (VCN) to
logical clusters (LCN). The NTFS3 subsystem also has a shortcut for
deleting files from MFT records - in this case, the RUN_DEALLOCATE
command is sent to the run_unpack input, and the function logic
provides that all data transferred to the runlist about file or
directory is deleted without creating a runs_tree structure.

Substituting the runlist in the $DATA attribute of the MFT record for an
arbitrary file can lead either to access to arbitrary data on the disk
bypassing access checks to them (since the inode access check
occurs above) or to destruction of arbitrary data on the disk.

Add overflow check for addition operation.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
References: https://git.kernel.org/stable/c/3ac37e100385b59ac821a[PII_REDACTED]2238aaac4; https://git.kernel.org/stable/c/5aa5799d162ad1b8e8b699d48b6218143c695a78; https://git.kernel.org/stable/c/736fc7bf5f68f6b74a0925b7e072c571838657d2
CVE: CVE-2025-40069
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Fix obj leak in VM_BIND error path

If we fail a handle-lookup part way thru, we need to drop the already
obtained obj references.

Patchwork: https://patchwork.freedesktop.org/patch/669784/
References: https://git.kernel.org/stable/c/278f8904434aa96055e793936b5977c010549e28; https://git.kernel.org/stable/c/2b512909a291a964cfcf6b58de13256ab3e848c4
CVE: CVE-2025-40070
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

pps: fix warning in pps_register_cdev when register device fail

Similar to previous commit 2a934fdb01db ("media: v4l2-dev: fix error
handling in __video_register_device()"), the release hook should be set
before device_register(). Otherwise, when device_register() return error
and put_device() try to callback the release function, the below warning
may happen.

  ------------[ cut here ]------------
  WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567
  Modules linked in:
  CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE
  RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567
  Call Trace:
   <TASK>
   kobject_cleanup+0x136/0x410 lib/kobject.c:689
   kobject_release lib/kobject.c:720 [inline]
   kref_put include/linux/kref.h:65 [inline]
   kobject_put+0xe9/0x130 lib/kobject.c:737
   put_device+0x24/0x30 drivers/base/core.c:3797
   pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402
   pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108
   pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57
   tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432
   tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563
   tiocsetd drivers/tty/tty_io.c:2429 [inline]
   tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:598 [inline]
   __se_sys_ioctl fs/ioctl.c:584 [inline]
   __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584
   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
   do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
   </TASK>

Before commit c79a39dc8d06 ("pps: Fix a use-after-free"),
pps_register_cdev() call device_create() to create pps->dev, which will
init dev->release to device_create_release(). Now the comment is outdated,
just remove it.

Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed
in pps_register_source() to avoid a double free in the failure case.
References: https://git.kernel.org/stable/c/0f97564a1fb62f34b3b498e2f12caffbe99c004a; https://git.kernel.org/stable/c/125527db[PII_REDACTED]8ee1aacd7f3ffe6a3a489c; https://git.kernel.org/stable/c/2a194707ca27a3b0523023fa8b446e5ec922dc51
CVE: CVE-2025-40071
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

tty: n_gsm: Don't block input queue by waiting MSC

Currently gsm_queue() processes incoming frames and when opening
a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().
If basic mode is used it calls gsm_modem_upd_via_msc() and it
cannot block the input queue by waiting the response to come
into the same input queue.

Instead allow sending Modem Status Command without waiting for remote
end to respond. Define a new function gsm_modem_send_initial_msc()
for this purpose. As MSC is only valid for basic encoding, it does
not do anything for advanced or when convergence layer type 2 is used.
References: https://git.kernel.org/stable/c/3cf0b3c243e56bc43be560617416c1d9f301f44c; https://git.kernel.org/stable/c/5416e89b81b00443cb03c88df8da097ae091a141; https://git.kernel.org/stable/c/c36785f9de03df56ff9b8eca30fa681a12b2310d
CVE: CVE-2025-40072
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

fanotify: Validate the return value of mnt_ns_from_dentry() before dereferencing

The function do_fanotify_mark() does not validate if
mnt_ns_from_dentry() returns NULL before dereferencing mntns->user_ns.
This causes a NULL pointer dereference in do_fanotify_mark() if the
path is not a mount namespace object.

Fix this by checking mnt_ns_from_dentry()'s return value before
dereferencing it.

Before the patch

$ gcc fanotify_nullptr.c -o fanotify_nullptr
$ mkdir A
$ ./fanotify_nullptr
Fanotify fd: 3
fanotify_mark: Operation not permitted
$ unshare -Urm
Fanotify fd: 3
Killed

int main(void){
    int ffd;
    ffd = fanotify_init(FAN_CLASS_NOTIF | FAN_REPORT_MNT, 0);
    if(ffd < 0){
        perror("fanotify_init");
        exit(EXIT_FAILURE);
    }

    printf("Fanotify fd: %d\n",ffd);

    if(fanotify_mark(ffd, FAN_MARK_ADD | FAN_MARK_MNTNS,
FAN_MNT_ATTACH, AT_FDCWD, "A") < 0){
        perror("fanotify_mark");
        exit(EXIT_FAILURE);
    }

return 0;
}

After the patch

$ gcc fanotify_nullptr.c -o fanotify_nullptr
$ mkdir A
$ ./fanotify_nullptr
Fanotify fd: 3
fanotify_mark: Operation not permitted
$ unshare -Urm
Fanotify fd: 3
fanotify_mark: Invalid argument

[   25.694973] BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
[   25.695006] #PF: supervisor read access in kernel mode
[   25.695012] #PF: error_code(0x0000) - not-present page
[   25.695017] PGD 109a30067 P4D 109a30067 PUD 142b46067 PMD 0
[   25.695025] Oops: Oops: 0000 [#1] SMP NOPTI
[   25.695032] CPU: 4 UID: 1000 PID: 1478 Comm: fanotify_nullpt Not
tainted 6.17.0-rc4 #1 PREEMPT(lazy)
[   25.695040] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
[   25.695049] RIP: 0010:do_fanotify_mark+0x817/0x950
[   25.695066] Code: 04 00 00 e9 45 fd ff ff 48 8b 7c 24 48 4c 89 54
24 18 4c 89 5c 24 10 4c 89 0c 24 e8 b3 11 fc ff 4c 8b 54 24 18 4c 8b
5c 24 10 <48> 8b 78 38 4c 8b 0c 24 49 89 c4 e9 13 fd ff ff 8b 4c 24 28
85 c9
[   25.695081] RSP: 0018:ffffd31c469e3c08 EFLAGS: 00010203
[   25.695104] RAX: [PII_REDACTED] RBX: [PII_REDACTED] RCX: ffff8eb48aebd220
[   25.695110] RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: ffff8eb4835e8180
[   25.695115] RBP: [PII_REDACTED] R08: [PII_REDACTED] R09: [PII_REDACTED]
[   25.695142] R10: ffff8eb48a7d56c0 R11: ffff8eb482bede00 R12:[PII_REDACTED]4012a7
[   25.695148] R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffff8eb48a7d56c0
[   25.695154] FS:  00007f8733bda740(0000) GS:ffff8eb61ce5f000(0000)
knlGS:[PII_REDACTED]
[   25.695162] CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
[   25.695170] CR2: [PII_REDACTED] CR3: [PII_REDACTED] CR4:[PII_REDACTED]3706f0
[   25.695201] Call Trace:
[   25.695209]  <TASK>
[   25.695215]  __x64_sys_fanotify_mark+0x1f/0x30
[   25.695222]  do_syscall_64+0x82/0x2c0
...
References: https://git.kernel.org/stable/c/62e59ffe8787b5550ccff70c30b6f6be6a3ac3dd; https://git.kernel.org/stable/c/73ce2a774ad6497cbd48dc4f8a5d699bc417f3fa
CVE: CVE-2025-40073
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/msm: Do not validate SSPP when it is not ready

Current code will validate current plane and previous plane to
confirm they can share a SSPP with multi-rect mode. The SSPP
is already allocated for previous plane, while current plane
is not associated with any SSPP yet. Null pointer is referenced
when validating the SSPP of current plane. Skip SSPP validation
for current plane.

Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
Mem abort info:
  ESR = 0x[PII_REDACTED]000004
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x04: level 0 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
  CM = 0, WnR = 0, TnD = 0, TagAccess = 0
  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=[PII_REDACTED]ac3000
[[PII_REDACTED]] pgd=[PII_REDACTED], p4d=[PII_REDACTED]
Internal error: Oops: [PII_REDACTED] [#1]  SMP
Modules linked in:
CPU: 4 UID: 0 PID: 1891 Comm: modetest Tainted: G S                  6.15.0-rc2-g3ee3f6e1202e #335 PREEMPT
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: SM8650 EV1 rev1 4slam 2et (DT)
pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : dpu_plane_is_multirect_capable+0x68/0x90
lr : dpu_assign_plane_resources+0x288/0x410
sp : ffff800093dcb770
x29: ffff800093dcb770 x28: [PII_REDACTED] x27: ffff000817c6c000
x26: ffff000806b46368 x25: ffff0008013f6080 x24: ffff00080cbf4800
x23: ffff[PII_REDACTED]80 x22: ffff0008013f1080 x21: ffff00080cc86080
x20: ffff000806b463b0 x19: ffff00080cbf5a00 x18: 00000000ffffffff
x17: 707a5f657a696c61 x16: [PII_REDACTED] x15: [PII_REDACTED]
x14: 00000000ffffffff x13: 00aaaaaa00aaaaaa x12: [PII_REDACTED]
x11: ffff000817c6e2b8 x10: [PII_REDACTED] x9 : ffff80008106a950
x8 : ffff00080cbf48f4 x7 : [PII_REDACTED] x6 : [PII_REDACTED]
x5 : [PII_REDACTED] x4 : [PII_REDACTED] x3 : [PII_REDACTED]
x2 : ffff800082e245e0 x1 : [PII_REDACTED] x0 : [PII_REDACTED]
Call trace:
 dpu_plane_is_multirect_capable+0x68/0x90 (P)
 dpu_crtc_atomic_check+0x5bc/0x650
 drm_atomic_helper_check_planes+0x13c/0x220
 drm_atomic_helper_check+0x58/0xb8
 msm_atomic_check+0xd8/0xf0
 drm_atomic_check_only+0x4a8/0x968
 drm_atomic_commit+0x50/0xd8
 drm_atomic_helper_update_plane+0x140/0x188
 __setplane_atomic+0xfc/0x148
 drm_mode_setplane+0x164/0x378
 drm_ioctl_kernel+0xc0/0x140
 drm_ioctl+0x20c/0x500
 __arm64_sys_ioctl+0xbc/0xf8
 invoke_syscall+0x50/0x120
 el0_svc_common.constprop.0+0x48/0xf8
 do_el0_svc+0x28/0x40
 el0_svc+0x30/0xd0
 el0t_64_sync_handler+0x144/0x168
 el0t_64_sync+0x198/0x1a0
Code: b9402021 370fffc1 f9[PII_REDACTED]ff81 (f94010a1)
---[ end trace [PII_REDACTED] ]---

Patchwork: https://patchwork.freedesktop.org/patch/669224/
References: https://git.kernel.org/stable/c/6fc616723bb5fd4289d7422fa013da062b44ae55; https://git.kernel.org/stable/c/f1dbb3eedb7db4cad45d2619edb1cce6041f79e3
CVE: CVE-2025-40074
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv4: start using dst_dev_rcu()

Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.

Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),
ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().
References: https://git.kernel.org/stable/c/6ad8de3cefdb6ffa6708b21c567df0dbf82c43a8; https://git.kernel.org/stable/c/923e0734c386984d45de508528a7a7ad91d791cc
CVE: CVE-2025-40075
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

tcp_metrics: use dst_dev_net_rcu()

Replace three dst_dev() with a lockdep enabled helper.
References: https://git.kernel.org/stable/c/07613a95326ebad2d1b88d883cd72546025a4f3e; https://git.kernel.org/stable/c/4b89397807eb04986427c4786d065e9442834ad4; https://git.kernel.org/stable/c/50c127a69cd[PII_REDACTED]853b352a1918cfa180f
CVE: CVE-2025-40076
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

PCI: rcar-host: Pass proper IRQ domain to generic_handle_domain_irq()

Starting with commit dd26c1a23fd5 ("PCI: rcar-host: Switch to
msi_create_parent_irq_domain()"), the MSI parent IRQ domain is NULL because
the object of type struct irq_domain_info passed to:

msi_create_parent_irq_domain() ->
  irq_domain_instantiate()() ->
    __irq_domain_instantiate()

has no reference to the parent IRQ domain. Using msi->domain->parent as an
argument for generic_handle_domain_irq() leads to below error:

	"Unable to handle kernel NULL pointer dereference at virtual address"

This error was identified while switching the upcoming RZ/G3S PCIe host
controller driver to msi_create_parent_irq_domain() (which was using a
similar pattern to handle MSIs (see link section)), but it was not tested
on hardware using the pcie-rcar-host controller driver due to lack of
hardware.

[mani: reworded subject and description]
References: https://git.kernel.org/stable/c/d3fee10e40a938331e2aae[PII_REDACTED]6db31304; https://git.kernel.org/stable/c/e8e21aaf5d34015901cd271053a67a62b4204526
CVE: CVE-2025-40077
Published: 2025-10-28
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to avoid overflow while left shift operation

Should cast type of folio->index from pgoff_t to loff_t to avoid overflow
while left shift operation.
References: https://git.kernel.org/stable/c/0e75a098b0a37f02ca31fe99ac16004c8163cf67; https://git.kernel.org/stable/c/0fe1c6bec54ea68ed8c987b3890f2296364e77bb; https://git.kernel.org/stable/c/57d3381dfb97ff73ddd18601017fec21cca80985