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

ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mapping

When an invalid value is passed via quirk option, currently
bytcr_rt5640 driver only shows an error message but leaves as is.
This may lead to unepxected results like OOB access.

This patch corrects the input mapping to the certain default value if
an invalid value is passed.
References: https://git.kernel.org/stable/c/29a41bf6422688f0c5a09b18222e1a64b2629fa4; https://git.kernel.org/stable/c/2c27e047bdcba457ec953f7e90e4ed6d5f8aeb01; https://git.kernel.org/stable/c/48880f3cdf2b6d8dcd91219c5b5c8a[PII_REDACTED]
CVE: CVE-2025-40155
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: debugfs: Fix legacy mode page table dump logic

In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR
maybe uninitialized or zero in that case and may cause oops like:

 Oops: general protection fault, probably for non-canonical address
       0xf00087d3f000f000: 0000 [#1] SMP NOPTI
 CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014
 RIP: 0010:pgtable_walk_level+0x98/0x150
 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206
 RAX: [PII_REDACTED] RBX: ffffc90000f27ab0 RCX:[PII_REDACTED]00001e
 RDX: [PII_REDACTED] RSI: f00087d3f000f000 RDI: f00087d3f0010000
 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: [PII_REDACTED]
 R10: [PII_REDACTED] R11: [PII_REDACTED] R12: f00087d3f000f000
 R13: [PII_REDACTED] R14: [PII_REDACTED] R15: ffffc90000f27a98
 FS: [PII_REDACTED]dcb740(0000) GS:ffff8881f812c000(0000) knlGS:[PII_REDACTED]
 CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
 CR2:[PII_REDACTED]d44000 CR3:[PII_REDACTED]d81003 CR4:[PII_REDACTED]772ef0
 PKRU: 55555554
 Call Trace:
  <TASK>
  pgtable_walk_level+0x88/0x150
  domain_translation_struct_show.isra.0+0x2d9/0x300
  dev_domain_translation_struct_show+0x20/0x40
  seq_read_iter+0x12d/0x490
...

Avoid walking the page table if TT is not 00b or 01b.
References: https://git.kernel.org/stable/c/d8cf7b59c49f9118fa875462e18686cb6b131bb5; https://git.kernel.org/stable/c/df2bf759a0bdb71f13e327d7527260d09facc055; https://git.kernel.org/stable/c/fbe6070c73badca726e4ff7877320e6c62339917
CVE: CVE-2025-40156
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

PM / devfreq: mtk-cci: Fix potential error pointer dereference in probe()

The drv->sram_reg pointer could be set to ERR_PTR(-EPROBE_DEFER) which
would lead to a error pointer dereference.  Use IS_ERR_OR_NULL() to check
that the pointer is valid.
References: https://git.kernel.org/stable/c/24d61b6e23d2c7291c528dd43a0bf76b5c05c8f0; https://git.kernel.org/stable/c/44e32104cf7e670e3d683c97b52350d8fac23322; https://git.kernel.org/stable/c/80eab6a9df7e1107dc334434dbacd[PII_REDACTED]7
CVE: CVE-2025-40157
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller

When loading the i10nm_edac driver on some Intel Granite Rapids servers,
a call trace may appear as follows:

  UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16
  shift exponent -66 is negative
  ...
  __ubsan_handle_shift_out_of_bounds+0x1e3/0x390
  skx_get_dimm_info.cold+0x47/0xd40 [skx_edac_common]
  i10nm_get_dimm_config+0x23e/0x390 [i10nm_edac]
  skx_register_mci+0x159/0x220 [skx_edac_common]
  i10nm_init+0xcb0/0x1ff0 [i10nm_edac]
  ...

This occurs because some BIOS may disable a memory controller if there
aren't any memory DIMMs populated on this memory controller. The DIMMMTR
register of this disabled memory controller contains the invalid value
~0, resulting in the call trace above.

Fix this call trace by skipping DIMM enumeration on a disabled memory
controller.
References: https://git.kernel.org/stable/c/1652f14cf3bef5a4baa232de954fc22bdcaa78fe; https://git.kernel.org/stable/c/2e6fe1bbefd9c059c3787d1c620fe67343a94dff; https://git.kernel.org/stable/c/8100b6c0f9089d5b156642b81270ce27fff17490
CVE: CVE-2025-40158
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: use RCU in ip6_output()

Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent
possible UAF.

We can remove rcu_read_lock()/rcu_read_unlock() pairs
from ip6_finish_output2().
References: https://git.kernel.org/stable/c/0393f85c3241c19ba8550f04a812e7d19f6b3082; https://git.kernel.org/stable/c/11709573cc4e48dc34c80fc7ab9ce5b159e29695
CVE: CVE-2025-40159
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

xsk: Harden userspace-supplied xdp_desc validation

Turned out certain clearly invalid values passed in xdp_desc from
userspace can pass xp_{,un}aligned_validate_desc() and then lead
to UBs or just invalid frames to be queued for xmit.

desc->len close to ``U32_MAX`` with a non-zero pool->tx_metadata_len
can cause positive integer overflow and wraparound, the same way low
enough desc->addr with a non-zero pool->tx_metadata_len can cause
negative integer overflow. Both scenarios can then pass the
validation successfully.
This doesn't happen with valid XSk applications, but can be used
to perform attacks.

Always promote desc->len to ``u64`` first to exclude positive
overflows of it. Use explicit check_{add,sub}_overflow() when
validating desc->addr (which is ``u64`` already).

bloat-o-meter reports a little growth of the code size:

add/remove: 0/0 grow/shrink: 2/1 up/down: 60/-16 (44)
Function                                     old     new   delta
xskq_cons_peek_desc                          299     330     +31
xsk_tx_peek_release_desc_batch               973    1002     +29
xsk_generic_xmit                            3148    3132     -16

but hopefully this doesn't hurt the performance much.
References: https://git.kernel.org/stable/c/07ca98f906a403637fc5e513a872a50ef1247f3b; https://git.kernel.org/stable/c/1463cd066f32efd56ddfd3ac4e3524200f362980; https://git.kernel.org/stable/c/5b5fffa7c81e55d8c8edf05ad40d811ec7047e21
CVE: CVE-2025-40160
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

xen/events: Return -EEXIST for bound VIRQs

Change find_virq() to return -EEXIST when a VIRQ is bound to a
different CPU than the one passed in.  With that, remove the BUG_ON()
from bind_virq_to_irq() to propogate the error upwards.

Some VIRQs are per-cpu, but others are per-domain or global.  Those must
be bound to CPU0 and can then migrate elsewhere.  The lookup for
per-domain and global will probably fail when migrated off CPU 0,
especially when the current CPU is tracked.  This now returns -EEXIST
instead of BUG_ON().

A second call to bind a per-domain or global VIRQ is not expected, but
make it non-fatal to avoid trying to look up the irq, since we don't
know which per_cpu(virq_to_irq) it will be in.
References: https://git.kernel.org/stable/c/07ce121d93a5e5fb2440a24da3dbf408fcee978e; https://git.kernel.org/stable/c/612ef6056855c0aacb9b25d1d853c435754483f7; https://git.kernel.org/stable/c/a1e7f07ae6b594f1ba5be46c6125b43bc505c5aa
CVE: CVE-2025-40161
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

mailbox: zynqmp-ipi: Fix SGI cleanup on unbind

The driver incorrectly determines SGI vs SPI interrupts by checking IRQ
number < 16, which fails with dynamic IRQ allocation. During unbind,
this causes improper SGI cleanup leading to kernel crash.

Add explicit irq_type field to pdata for reliable identification of SGI
interrupts (type-2) and only clean up SGI resources when appropriate.
References: https://git.kernel.org/stable/c/1ee147efee68be00203b1fee6479911debb1edb2; https://git.kernel.org/stable/c/32bf7c6e01f5ba17a53ba236a770bd0274cefdf4; https://git.kernel.org/stable/c/bb160e791ab15b89188a7a19589b8e11f681bef3
CVE: CVE-2025-40162
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails

devm_kasprintf() may return NULL on memory allocation failure,
but the debug message prints cpus->dai_name before checking it.
Move the dev_dbg() call after the NULL check to prevent potential
NULL pointer dereference.
References: https://git.kernel.org/stable/c/095d692e5997ece300c89f10d903d5230090e6a0; https://git.kernel.org/stable/c/5726b68473f7153a7f6294185e5998b7e2a230a2; https://git.kernel.org/stable/c/a1cccbd19676fc36854535a7118ba2c27d0b84b3
CVE: CVE-2025-40163
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

sched/deadline: Stop dl_server before CPU goes offline

IBM CI tool reported kernel warning[1] when running a CPU removal
operation through drmgr[2]. i.e "drmgr -c cpu -r -q 1"

WARNING: CPU: 0 PID: 0 at kernel/sched/cpudeadline.c:219 cpudl_set+0x58/0x170
NIP [c[PII_REDACTED]b6ed8] cpudl_set+0x58/0x170
LR [c[PII_REDACTED]b7cb8] dl_server_timer+0x168/0x2a0
Call Trace:
[c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable)
[c[PII_REDACTED]b7cb8] dl_server_timer+0x168/0x2a0
[c[PII_REDACTED]4df84] __hrtimer_run_queues+0x1a4/0x390
[c[PII_REDACTED]4f624] hrtimer_interrupt+0x124/0x300
[c[PII_REDACTED]2a230] timer_interrupt+0x140/0x320

Git bisects to: commit 4ae8d9aa9f9d ("sched/deadline: Fix dl_server getting stuck")

This happens since:
- dl_server hrtimer gets enqueued close to cpu offline, when
  kthread_park enqueues a fair task.
- CPU goes offline and drmgr removes it from cpu_present_mask.
- hrtimer fires and warning is hit.

Fix it by stopping the dl_server before CPU is marked dead.

[1]: https://lore.kernel.org/all/8218e149-7718-4432-9312-f97297c352b9@linux.ibm.com/
[2]: https://github.com/ibm-power-utilities/powerpc-utils/tree/next/src/drmgr

[sshegde: wrote the changelog and tested it]
References: https://git.kernel.org/stable/c/ab6c0f158508bb16d483add70b73a73f95651c33; https://git.kernel.org/stable/c/ee6e44dfe6e50b4a5df853d933a96bdff5309e6e
CVE: CVE-2025-40164
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

usbnet: Fix using smp_processor_id() in preemptible code warnings

Syzbot reported the following warning:

BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879
caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331
CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120
 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49
 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331
 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708
 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417
 __dev_set_mtu net/core/dev.c:9443 [inline]
 netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496
 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520
 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247
 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572
 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821
 sock_do_ioctl+0x19d/0x280 net/socket.c:1204
 sock_ioctl+0x42f/0x6a0 net/socket.c:1311
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:906 [inline]
 __se_sys_ioctl fs/ioctl.c:892 [inline]
 __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

For historical and portability reasons, the netif_rx() is usually
run in the softirq or interrupt context, this commit therefore add
local_bh_disable/enable() protection in the usbnet_resume_rx().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0134c7bff14bd50314a4f92b182850ddfc38e255; https://git.kernel.org/stable/c/17fbad93879e87a334062882b45fa727ba1b3dd7; https://git.kernel.org/stable/c/327cd4b68b4398b6c24f10eb2b2533ffbfc10185
CVE: CVE-2025-40165
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

media: nxp: imx8-isi: m2m: Fix streaming cleanup on release

If streamon/streamoff calls are imbalanced, such as when exiting an
application with Ctrl+C when streaming, the m2m usage_count will never
reach zero and the ISI channel won't be freed. Besides from that, if the
input line width is more than 2K, it will trigger a WARN_ON():

[ 59.222120] ------------[ cut here ]------------
[ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654
[ 59.238569] Modules linked in: ap1302
[ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20[PII_REDACTED]1-gff0e002d480a-dirty #258 PREEMPT
[ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT)
[ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120
[ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120
[ 59.275047] sp : ffff8000848c3b40
[ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00
[ 59.285472] x26:[PII_REDACTED]00000a x25: ffff0000859b4cb8 x24: [PII_REDACTED]
[ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780
[ 59.299720] x20: ffff000084342ff8 x19: ffff[PII_REDACTED]00 x18: [PII_REDACTED]
[ 59.306845] x17: [PII_REDACTED] x16: [PII_REDACTED] x15: 0000ffffdb369e1c
[ 59.313969] x14: [PII_REDACTED] x13: [PII_REDACTED] x12: [PII_REDACTED]
[ 59.321093] x11: [PII_REDACTED] x10: [PII_REDACTED] x9 : [PII_REDACTED]
[ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30
[ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff[PII_REDACTED]20
[ 59.342464] x2 : ffff0000852f6900 x1 : [PII_REDACTED] x0 : ffff[PII_REDACTED]00
[ 59.349590] Call trace:
[ 59.352025]  mxc_isi_channel_chain+0xa4/0x120 (P)
[ 59.356722]  mxc_isi_m2m_streamon+0x160/0x20c
[ 59.361072]  v4l_streamon+0x24/0x30
[ 59.364556]  __video_do_ioctl+0x40c/0x4a0
[ 59.368560]  video_usercopy+0x2bc/0x690
[ 59.372382]  video_ioctl2+0x18/0x24
[ 59.375857]  v4l2_ioctl+0x40/0x60
[ 59.379168]  __arm64_sys_ioctl+0xac/0x104
[ 59.383172]  invoke_syscall+0x48/0x104
[ 59.386916]  el0_svc_common.constprop.0+0xc0/0xe0
[ 59.391613]  do_el0_svc+0x1c/0x28
[ 59.394915]  el0_svc+0x34/0xf4
[ 59.397966]  el0t_64_sync_handler+0xa0/0xe4
[ 59.402143]  el0t_64_sync+0x198/0x19c
[ 59.405801] ---[ end trace [PII_REDACTED] ]---

Address this issue by moving the streaming preparation and cleanup to
the vb2 .prepare_streaming() and .unprepare_streaming() operations. This
also simplifies the driver by allowing direct usage of the
v4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.
References: https://git.kernel.org/stable/c/178aa[PII_REDACTED]dd91e7dbc2eb984525886c9c1; https://git.kernel.org/stable/c/50c721be2cff2bf8c9a5f1f4add35c2bbb1df302; https://git.kernel.org/stable/c/b0d438c7b43314f9128e0dda5f83789e593e684a
CVE: CVE-2025-40166
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/guc: Check GuC running state before deregistering exec queue

In normal operation, a registered exec queue is disabled and
deregistered through the GuC, and freed only after the GuC confirms
completion. However, if the driver is forced to unbind while the exec
queue is still running, the user may call exec_destroy() after the GuC
has already been stopped and CT communication disabled.

In this case, the driver cannot receive a response from the GuC,
preventing proper cleanup of exec queue resources. Fix this by directly
releasing the resources when GuC is not running.

Here is the failure dmesg log:
"
[  468.089581] ---[ end trace [PII_REDACTED] ]---
[  468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)
[  468.090558] pci 0000:03:00.0: [drm] GT0:     total 65535
[  468.090562] pci 0000:03:00.0: [drm] GT0:     used 1
[  468.090564] pci 0000:03:00.0: [drm] GT0:     range 1..1 (1)
[  468.092716] ------------[ cut here ]------------
[  468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]
"

v2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().
    As CT may go down and come back during VF migration.

(cherry picked from commit 9b42321a02c50a12b2beb6ae[PII_REDACTED]fbecea)
References: https://git.kernel.org/stable/c/2c6e5904c5bdbac8e0eadee40f70c42bb83f6dc6; https://git.kernel.org/stable/c/9f64b3cd051b825de0a2a9f145c8e003200cedd5; https://git.kernel.org/stable/c/fa708415566bbe5361c[PII_REDACTED]19f8edc8dc1
CVE: CVE-2025-40167
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: detect invalid INLINE_DATA + EXTENTS flag combination

syzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verity
file on a corrupted ext4 filesystem mounted without a journal.

The issue is that the filesystem has an inode with both the INLINE_DATA
and EXTENTS flags set:

    EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15:
    comm syz.0.17: corrupted extent tree: lblk 0 < prev 66

Investigation revealed that the inode has both flags set:
    DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1

This is an invalid combination since an inode should have either:
- INLINE_DATA: data stored directly in the inode
- EXTENTS: data stored in extent-mapped blocks

Having both flags causes ext4_has_inline_data() to return true, skipping
extent tree validation in __ext4_iget(). The unvalidated out-of-order
extents then trigger a BUG_ON in ext4_es_cache_extent() due to integer
underflow when calculating hole sizes.

Fix this by detecting this invalid flag combination early in ext4_iget()
and rejecting the corrupted inode.
References: https://git.kernel.org/stable/c/1437c95ab2a28b138d[PII_REDACTED]729f61ccb48b; https://git.kernel.org/stable/c/1d3ad183943b38eec2acf72a0ae98e635dc8456b; https://git.kernel.org/stable/c/1f5ccd22ff482639133f2a0fe08f6d19d0e68717
CVE: CVE-2025-40168
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().

smc_clc_prfx_match() is called from smc_listen_work() and
not under RCU nor RTNL.

Using sk_dst_get(sk)->dev could trigger UAF.

Let's use __sk_dst_get() and dst_dev_rcu().

Note that the returned value of smc_clc_prfx_match() is not
used in the caller.
References: https://git.kernel.org/stable/c/235f81045c008169cc4e1955b4a64e118eebe61b; https://git.kernel.org/stable/c/d26e80f7fb62d77757b67a1b94e4ac756bc9c658
CVE: CVE-2025-40169
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject negative offsets for ALU ops

When verifying BPF programs, the check_alu_op() function validates
instructions with ALU operations. The 'offset' field in these
instructions is a signed 16-bit integer.

The existing check 'insn->off > 1' was intended to ensure the offset is
either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is
signed, this check incorrectly accepts all negative values (e.g., -1).

This commit tightens the validation by changing the condition to
'(insn->off != 0 && insn->off != 1)'. This ensures that any value
other than the explicitly permitted 0 and 1 is rejected, hardening the
verifier against malformed BPF programs.
References: https://git.kernel.org/stable/c/21167bf70dbe400563e189ac632258d35eda38b5; https://git.kernel.org/stable/c/3bce44b344040e5eef3d64d38b157c15304c0aab; https://git.kernel.org/stable/c/5017c302ca4b2a45149ad64e058fa2d5623c068f
CVE: CVE-2025-40170
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net: use dst_dev_rcu() in sk_setup_caps()

Use RCU to protect accesses to dst->dev from sk_setup_caps()
and sk_dst_gso_max_size().

Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),
and ip_dst_mtu_maybe_forward().

ip4_dst_hoplimit() can use dst_dev_net_rcu().
References: https://git.kernel.org/stable/c/5d1be493d1110c9e720b4c51a6e587bb2fb4ac12; https://git.kernel.org/stable/c/99a2ace61b211b0be861b07fbaa062fca4b58879; https://git.kernel.org/stable/c/a805729c0091073d8f0415cfa96c7acd1bc17a48
CVE: CVE-2025-40171
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

nvmet-fc: move lsop put work to nvmet_fc_ls_req_op

It’s possible for more than one async command to be in flight from
__nvmet_fc_send_ls_req. For each command, a tgtport reference is taken.

In the current code, only one put work item is queued at a time, which
results in a leaked reference.

To fix this, move the work item to the nvmet_fc_ls_req_op struct, which
already tracks all resources related to the command.
References: https://git.kernel.org/stable/c/060ecc81240ef9d60d9485a3a5eb55a0d6e7a25c; https://git.kernel.org/stable/c/11269c08013f4ee8b8f5edc6c56700acb34092d0; https://git.kernel.org/stable/c/7331925c247b03b7767b8cd93cfe1b7aa2377850
CVE: CVE-2025-40172
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()

Currently, if find_and_map_user_pages() takes a DMA xfer request from the
user with a length field set to 0, or in a rare case, the host receives
QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size
is equal to the requested transaction size, the function will return 0
before allocating an sgt or setting the fields of the dma_xfer struct.
In that case, encode_addr_size_pairs() will try to access the sgt which
will lead to a general protection fault.

Return an EINVAL in case the user provides a zero-sized ALP, or the device
requests continuation after all of the bytes have been transferred.
References: https://git.kernel.org/stable/c/11f08c30a3e4157305ba692f1d44cca5fc9a8fca; https://git.kernel.org/stable/c/1ab9733d14cc9987cc5dcd1f0ad1f416e302e2e6; https://git.kernel.org/stable/c/48b1d42286bfef7628b1d6c8c28d4e456c90f725
CVE: CVE-2025-40173
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

net/ip6_tunnel: Prevent perpetual tunnel growth

Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.
While ipv4 tunnel headroom adjustment growth was limited in
commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),
ipv6 tunnel yet increases the headroom without any ceiling.

Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.

Credits to Francesco Ruggeri, who was originally debugging this issue
and wrote local Arista-specific patch and a reproducer.
References: https://git.kernel.org/stable/c/10fe967efe73c610e526ff[PII_REDACTED]633dee9c; https://git.kernel.org/stable/c/11f6066af3bfb8149aa16c42c0b0c5ea5b199a94; https://git.kernel.org/stable/c/21f4d45eba0b2dcae5dbc9e5e0ad08735c993f16
CVE: CVE-2025-40174
Published: 2025-11-12
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/mm: Fix SMP ordering in switch_mm_irqs_off()

Stephen noted that it is possible to not have an smp_mb() between
the loaded_mm store and the tlb_gen load in switch_mm(), meaning the
ordering against flush_tlb_mm_range() goes out the window, and it
becomes possible for switch_mm() to not observe a recent tlb_gen
update and fail to flush the TLBs.

[ dhansen: merge conflict fixed by Ingo ]
References: https://git.kernel.org/stable/c/0fe5e3f5fb75c5d88dad24dece3ee75e9d87adeb; https://git.kernel.org/stable/c/83b0177a6c4889b3a6e865da5e21b2c9d97d0551