Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8 Soft lockup is not triggered with THP or base page because there is cond_resched() called for each PMD size. Although the soft lockup was triggered by MTE, it should be not MTE specific. The other processing which takes long time in the loop may trigger soft lockup too. So add cond_resched() for hugetlb to avoid soft lockup. References: - https://git.kernel.org/stable/c/30498c44c2a0b20f6833ed7d8fc3df901507f760 - https://git.kernel.org/stable/c/5783485ab2be06be5312b26c8793526edc09123d - https://git.kernel.org/stable/c/547e123e9d342a44c756446640ed847a8aeec611 - https://git.kernel.org/sta
8793526edc09123d - https://git.kernel.org/stable/c/547e123e9d342a44c756446640ed847a8aeec611 - https://git.kernel.org/stable/c/957faf9582f92bb2be8ebe4ab6aa1c2bc71d9859 - https://git.kernel.org/stable/c/964598e6f70a1be9fe675280bf16b4f96b0a6809 - https://git.kernel.org/stable/c/4975c975ed9457a77953a26aeef85fdba7cf5498 - https://git.kernel.org/stable/c/c6096f3947f68f96defedb8764b3b1ca4cf3469f - https://git.kernel.org/stable/c/f52ce0ea90c83a28904c7cc203a70e6434adfecb
CVE ID: CVE-2025-40154 State: PUBLISHED Published: 2025-11-12T10:23:28.470Z Last Updated: 2025-11-12T10:23:28.470Z Vendors: Linux Products: Linux 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/2c27e047bdcba457ec953f7e90e4ed6d5f8aeb01 - https://git.kernel.org/stable/c/a97b4d18ecb012c5
ps://git.kernel.org/stable/c/2c27e047bdcba457ec953f7e90e4ed6d5f8aeb01 - https://git.kernel.org/stable/c/a97b4d18ecb012c5624cdf2cab2ce5e1312fdd5d - https://git.kernel.org/stable/c/dea9c8c9028c9374761224a7f9d824e845a2aa2e - https://git.kernel.org/stable/c/f58fca15f3bf8b982e799c31e4afa8923788aa40 - https://git.kernel.org/stable/c/29a41bf6422688f0c5a09b18222e1a64b2629fa4 - https://git.kernel.org/stable/c/5c03ea2ef4ebba75c69c90929d8590eb3d3797a9 - https://git.kernel.org/stable/c/48880f3cdf2b6d8dcd91219c5b5c8a7526411322 - https://git.kernel.org/stable/c/fba404e4b4af4f4f747bb0e41e9fff7d03c7bcc0
CVE ID: CVE-2025-40155 State: PUBLISHED Published: 2025-11-12T10:23:28.718Z Last Updated: 2025-11-12T10:23:28.718Z Vendors: Linux Products: Linux 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:pgtab
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: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000
00000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 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 ID: CVE-2025-40156 State: PUBLISHED Published: 2025-11-12T10:23:28.994Z Last Updated: 2025-11-12T10:23:28.994Z Vendors: Linux Products: Linux 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/9cc23e221f392304b7b8aad213812564ddf6517e - https://git.kernel.org/stable/c/80eab6a9df7e1107dc334434dbacd05297703377 - https://git.kernel.org/stable/c/44e32104cf7e670e3d683c97b52350d8
org/stable/c/80eab6a9df7e1107dc334434dbacd05297703377 - https://git.kernel.org/stable/c/44e32104cf7e670e3d683c97b52350d8fac23322 - https://git.kernel.org/stable/c/24d61b6e23d2c7291c528dd43a0bf76b5c05c8f0 - https://git.kernel.org/stable/c/fc33bf0e097c6834646b98a7b3da0ae5b617f0f9
CVE ID: CVE-2025-40157 State: PUBLISHED Published: 2025-11-12T10:23:29.258Z Last Updated: 2025-11-12T10:23:29.258Z Vendors: Linux Products: Linux 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_i
[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/8100b6c0f9089d5b156642b81270ce27fff17490 - https://git.kernel.org/stable/c/1652f14cf3bef5a4baa232de954fc22bdcaa78fe - https://git.kernel.org/stable/c/c20da24272f1ac
ttps://git.kernel.org/stable/c/1652f14cf3bef5a4baa232de954fc22bdcaa78fe - https://git.kernel.org/stable/c/c20da24272f1ac79e9f9083bba577d049cd02bbb - https://git.kernel.org/stable/c/2e6fe1bbefd9c059c3787d1c620fe67343a94dff
CVE ID: CVE-2025-40158 State: PUBLISHED Published: 2025-11-12T10:23:29.516Z Last Updated: 2025-11-12T10:23:29.516Z Vendors: Linux Products: Linux 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 ID: CVE-2025-40159 State: PUBLISHED Published: 2025-11-12T10:24:36.104Z Last Updated: 2025-11-12T10:24:36.104Z Vendors: Linux Products: Linux 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 sc
d, 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 hur
sc 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/1463cd066f32efd56ddfd3ac4e3524200f362980 - https://git.kernel.org/stable/c/5b5fffa7c81e55d8c8edf05ad40d811ec7047e21 - https://git.kernel.org/stable/c/07ca98f906a403637fc5e513a872a50ef1247f3b
CVE ID: CVE-2025-40160 State: PUBLISHED Published: 2025-11-12T10:24:36.429Z Last Updated: 2025-11-12T10:24:36.429Z Vendors: Linux Products: Linux 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 track
he 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/612ef6056855c0aacb9b25d1d853c435754483f7 - https://git.kernel.org/stable/c/a1e7f07ae6b594f1ba5be46c6125b43bc505c5aa - https://git.kernel.org/stable/c/f81db055a793eca9d05f79658ff62adafb41d664 - https://git.kernel.org/stable/c/07ce121d93a5e5fb2440a24da3dbf408fcee978e
CVE ID: CVE-2025-40161 State: PUBLISHED Published: 2025-11-12T10:24:36.696Z Last Updated: 2025-11-12T10:24:36.696Z Vendors: Linux Products: Linux 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/1ee147efee68be00203b1fee6479911debb1edb
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 ID: CVE-2025-40162 State: PUBLISHED Published: 2025-11-12T10:26:22.883Z Last Updated: 2025-11-12T10:26:22.883Z Vendors: Linux Products: Linux 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/a1cccbd19676fc36854535a7118ba2c27d0b84b3 - https://git.kernel.org/s
10d903d5230090e6a0 - https://git.kernel.org/stable/c/a1cccbd19676fc36854535a7118ba2c27d0b84b3 - https://git.kernel.org/stable/c/5726b68473f7153a7f6294185e5998b7e2a230a2
CVE ID: CVE-2025-40163 State: PUBLISHED Published: 2025-11-12T10:26:23.199Z Last Updated: 2025-11-12T10:26:23.199Z Vendors: Linux Products: Linux 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 [c0000000002b6ed8] cpudl_set+0x58/0x170 LR [c0000000002b7cb8] dl_server_timer+0x168/0x2a0 Call Trace: [c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable) [c0000000002b7cb8] dl_server_timer+0x168/0x2a0 [c0000000
Trace: [c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable) [c0000000002b7cb8] dl_server_timer+0x168/0x2a0 [c00000000034df84] __hrtimer_run_queues+0x1a4/0x390 [c00000000034f624] hrtimer_interrupt+0x124/0x300 [c00000000002a230] 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.co
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 ID: CVE-2025-40164 State: PUBLISHED Published: 2025-11-12T10:26:23.482Z Last Updated: 2025-11-12T10:26:23.482Z Vendors: Linux Products: Linux 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
tary) 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 n
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(). References: - https://git.kernel.org/stable/c/0134c7bff14bd5
l_bh_disable/enable() protection in the usbnet_resume_rx(). References: - https://git.kernel.org/stable/c/0134c7bff14bd50314a4f92b182850ddfc38e255 - https://git.kernel.org/stable/c/327cd4b68b4398b6c24f10eb2b2533ffbfc10185
CVE ID: CVE-2025-40165 State: PUBLISHED Published: 2025-11-12T10:26:23.806Z Last Updated: 2025-11-12T10:26:23.806Z Vendors: Linux Products: Linux 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_c
-------[ 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-20250704-06511-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: 00
p : ffff8000848c3b40 [ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00 [ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001 [ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780 [ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000 [ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c [ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30 [ 59.335340] x5 : ffff0000859b6000 x4 : ffff800
28217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30 [ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420 [ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000 [ 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/
4 [ 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 0000000000000000 ]--- 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/50c721be2cff2bf8c9a5f1f4add35c2bbb1df302 - https://git.kernel.org/stable/c/e8b5f4d80775835cf8192d6
t.kernel.org/stable/c/50c721be2cff2bf8c9a5f1f4add35c2bbb1df302 - https://git.kernel.org/stable/c/e8b5f4d80775835cf8192d65138e9be1ff202847 - https://git.kernel.org/stable/c/b0d438c7b43314f9128e0dda5f83789e593e684a - https://git.kernel.org/stable/c/178aa3360220231dd91e7dbc2eb984525886c9c1
CVE ID: CVE-2025-40166 State: PUBLISHED Published: 2025-11-12T10:26:24.143Z Last Updated: 2025-11-12T10:26:24.143Z Vendors: Linux Products: Linux 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 pro
n 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 0000000000000000 ]--- [ 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_vr
----[ 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 9b42321a02c50a12b2beb6ae9469606257fbecea) References: - https://git.kernel.org/stable/c/2c6e5904c5bdbac8e0eadee40f70c42bb83f6dc6 - https://git.kernel.org/stable/c/fa708415566bbe5361c935645107319f8edc8dc1 - https://git.kernel.org/stable/c/9f64b3cd051b825de0a2a9f145c8e003200cedd5
CVE ID: CVE-2025-40167 State: PUBLISHED Published: 2025-11-12T10:26:24.498Z Last Updated: 2025-11-12T10:26:24.498Z Vendors: Linux Products: Linux 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: DEBU
5: 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 corru