Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- References: - https://git.kernel.org/stable/c/4f4b9ca73f84130d9fbb0fc02306ce94ce8bdbe6 - https://git.kernel.org/stable/c/289498da343b05c886f19b4269429606f86dd17b - https://git.kernel.org/stable/c/3fdcfd91b93f930d87843156c7c8cc5fbcf9b144 - https://git.kernel.org/stable/c/eb145463f22d7d32d426b29fe9810de9e792b6ba - https://git.kernel.org/stable/c/a5a51bf4
44 - https://git.kernel.org/stable/c/eb145463f22d7d32d426b29fe9810de9e792b6ba - https://git.kernel.org/stable/c/a5a51bf4e9b7354ce7cd697e610d72c1b33fd949
CVE ID: CVE-2025-40101 State: PUBLISHED Published: 2025-10-30T09:48:07.155Z Last Updated: 2025-10-30T09:48:07.155Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: btrfs: fix memory leaks when rejecting a non SINGLE data profile without an RST At the end of btrfs_load_block_group_zone_info() the first thing we do is to ensure that if the mapping type is not a SINGLE one and there is no RAID stripe tree, then we return early with an error. Doing that, though, prevents the code from running the last calls from this function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we
s function which are about freeing memory allocated during its run. Hence, in this case, instead of returning early, we set the ret value and fall through the rest of the cleanup code. References: - https://git.kernel.org/stable/c/187333e6d484c6630286bfdd07c79d6815a63887 - https://git.kernel.org/stable/c/602701d00439e113331ee9c1283e95afdcb8849d - https://git.kernel.org/stable/c/fec9b9d3ced39f16be8d7afdf81f4dd2653da319
CVE ID: CVE-2025-40102 State: PUBLISHED Published: 2025-10-30T09:48:07.790Z Last Updated: 2025-10-30T09:48:07.790Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Prevent access to vCPU events before init Another day, another syzkaller bug. KVM erroneously allows userspace to pend vCPU events for a vCPU that hasn't been initialized yet, leading to KVM interpreting a bunch of uninitialized garbage for routing / injecting the exception. In one case the injection code and the hyp disagree on whether the vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() du
e vCPU has a 32bit EL1 and put the vCPU into an illegal mode for AArch64, tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 000000000
0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm
000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000) Reject the ioctls outright as no sane VMM would call these before KVM_ARM_VCPU_INIT anyway. Even if it did the exception would've been thrown away by the eventual reset of the vCPU's state. References: - https://git.kernel.org/stable/c/64a04e6320fc5affb
n thrown away by the eventual reset of the vCPU's state. References: - https://git.kernel.org/stable/c/64a04e6320fc5affbadc59dc7024d79f909bfe84 - https://git.kernel.org/stable/c/0aa1b76fe1429629215a7c79820e4b96233ac4a3
CVE ID: CVE-2025-40103 State: PUBLISHED Published: 2025-10-30T09:48:08.421Z Last Updated: 2025-10-30T09:48:08.421Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix refcount leak for cifs_sb_tlink Fix three refcount inconsistency issues related to `cifs_sb_tlink`. Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be called after successful calls to `cifs_sb_tlink()`. Three calls fail to update refcount accordingly, leading to possible resource leaks. References: - https://git.kernel.org/stable/c/790282abe9d805f08618c1c24ea2529e7259b692 - https://git.kernel.org/stable/c/d7dd034c14928306db1b46be277
rnel.org/stable/c/790282abe9d805f08618c1c24ea2529e7259b692 - https://git.kernel.org/stable/c/d7dd034c14928306db1b46be277ae439b84dacf9 - https://git.kernel.org/stable/c/e15605b68b490186da2ad8029c0351a9cfb0b9af - https://git.kernel.org/stable/c/896bb31e1416f582503db1350cf1bd10dc64e5a6 - https://git.kernel.org/stable/c/c2b77f42205ef485a647f62082c442c1cd69d3fc
CVE ID: CVE-2025-40104 State: PUBLISHED Published: 2025-10-30T09:48:09.051Z Last Updated: 2025-10-30T09:48:09.051Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ixgbevf: fix mailbox API compatibility by negotiating supported features There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API. This convention has been broken since introducing API 1.4. Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel
offload code") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself. Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to
tered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes. The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX. To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced
iver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox. New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op. Features negotiation mechanism gives possibility to be extended with new features when needed in the future. References: - https://git.kernel.org/stable/c/871ac1cd4ce4804defcb428cbb003fd84c415ff4 - https://git.kernel.org/stable/c/2e0aab9ddaf1428602c78f12064cd1e6ffcc4d18 - https://git.kernel.org/stable/c/bf580112ed61736c2645a893413a04732505d4b1 - https://git.kernel.org/sta
064cd1e6ffcc4d18 - https://git.kernel.org/stable/c/bf580112ed61736c2645a893413a04732505d4b1 - https://git.kernel.org/stable/c/a376e29b1b196dc90b50df7e5e3947e3026300c4 - https://git.kernel.org/stable/c/a7075f501bd33c93570af759b6f4302ef0175168
CVE ID: CVE-2025-40105 State: PUBLISHED Published: 2025-10-30T09:48:09.674Z Last Updated: 2025-10-30T09:48:09.674Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: vfs: Don't leak disconnected dentries on umount When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are try
s or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnec
non") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well. References: - https://git.kernel.org/stable/c/b5abafd0aa8d7bcb935c8f91e4cfc2f28207
t are marked as disconnected as well. References: - https://git.kernel.org/stable/c/b5abafd0aa8d7bcb935c8f91e4cfc2f2820759e4 - https://git.kernel.org/stable/c/20863bb7fbb016379f8227122edfabc5c799bc79 - https://git.kernel.org/stable/c/8004d4b8cbf1bd68a23c160d57287e177c82cc69 - https://git.kernel.org/stable/c/7e0c8aaf4e28918abded547a5147c7d52c4af7d2 - https://git.kernel.org/stable/c/cebfbf40056a4d858b2a3ca59a69936d599bd209 - https://git.kernel.org/stable/c/620f3b0ede9c5cb4976cd0457d0b04ad551e5d6b - https://git.kernel.org/stable/c/eadc49999fa994d6fbd70c332bd5d5051cc42261 - https://git.kernel.org/stable/c/56094ad3eaa21e6621396cc33811d8f72847a834
CVE ID: CVE-2025-40106 State: PUBLISHED Published: 2025-10-31T09:41:46.740Z Last Updated: 2025-10-31T09:41:46.740Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !m
handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands. References: - https://git.kernel.org/stable/c/4ffea48c69cb2b96a281cb7e5e42d706996631db - https://git.kernel.org/stable/c/8f3e4cd9be4b47246ea73ce5e3e0fa2f57f0d10c - https://git.kernel.org/stable/c/2670932f2465793fea1ef073e40883e8390fa4d9 - https://git.kernel.org/stable/c/6db19822512396be1a3e1e20c16c97270285ba1a - https://git.kernel.org/stable/c/d4854eff25efb06d0d84c13e712
rnel.org/stable/c/6db19822512396be1a3e1e20c16c97270285ba1a - https://git.kernel.org/stable/c/d4854eff25efb06d0d84c13e7129bbdba4125f8c - https://git.kernel.org/stable/c/a4bb5d1bc2f238461bcbe5303eb500466690bb2c - https://git.kernel.org/stable/c/55520f65fd447e04099a2c44185453c18ea73b7e - https://git.kernel.org/stable/c/87b318ba81dda2ee7b603f4f6c55e78ec3e95974
CVE ID: CVE-2025-40107 State: PUBLISHED Published: 2025-11-03T12:15:12.587Z Last Updated: 2025-11-03T12:15:12.587Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: can: hi311x: fix null pointer dereference when resuming from sleep before interface was enabled This issue is similar to the vulnerability in the `mcp251x` driver, which was fixed in commit 03c427147b2d ("can: mcp251x: fix resume from sleep before interface was brought up"). In the `hi311x` driver, when the device resumes from sleep, the driver schedules `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is no
les `priv->restart_work`. However, if the network interface was not previously enabled, the `priv->wq` (workqueue) is not allocated and initialized, leading to a null pointer dereference. To fix this, we move the allocation and initialization of the workqueue from the `hi3110_open` function to the `hi3110_can_probe` function. This ensures that the workqueue is properly initialized before it is used during device resume. And added logic to destroy the workqueue in the error handling paths of `hi3110_can_probe` and in the `hi3110_can_remove` function to prevent resource leaks. References: - https://git.kernel.org/stable/c/d1fc4c041459e2d4856c1b2501486ba4f0cbf96b - https://git.kernel.org/stable
. References: - https://git.kernel.org/stable/c/d1fc4c041459e2d4856c1b2501486ba4f0cbf96b - https://git.kernel.org/stable/c/e93af787187e585933570563c643337fa731584a - https://git.kernel.org/stable/c/1d2ef21f02baff0c109ad78b9e835fb4acb14533 - https://git.kernel.org/stable/c/fd00cf38fd437c979f0e5905e3ebdfc3f55a4b96 - https://git.kernel.org/stable/c/6b696808472197b77b888f50bc789a3bae077743
CVE ID: CVE-2025-40108 State: PUBLISHED Published: 2025-11-09T04:35:58.587Z Last Updated: 2025-11-09T04:35:58.587Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: serial: qcom-geni: Fix blocked task Revert commit 1afa70632c39 ("serial: qcom-geni: Enable PM runtime for serial driver") and its dependent commit 86fa39dd6fb7 ("serial: qcom-geni: Enable Serial on SA8255p Qualcomm platforms") because the first one causes regression - hang task on Qualcomm RB1 board (QRB2210) and unable to use serial at all during normal boot: INFO: task kworker/u16:0:12 blocked for more than 42 seconds. Not tainted 6.17.0-rc1-00004-g53e760d89498 #9 "e
mal boot: INFO: task kworker/u16:0:12 blocked for more than 42 seconds. Not tainted 6.17.0-rc1-00004-g53e760d89498 #9 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack:0 pid:12 tgid:12 ppid:2 task_flags:0x4208060 flags:0x00000010 Workqueue: async async_run_entry_fn Call trace: __switch_to+0xe8/0x1a0 (T) __schedule+0x290/0x7c0 schedule+0x34/0x118 rpm_resume+0x14c/0x66c rpm_resume+0x2a4/0x66c rpm_resume+0x2a4/0x66c rpm_resume+0x2a4/0x66c __pm_runtime_resume+0x50/0x9c __driver_probe_device+0x58/0x120 driver_probe_device+0x3c/0x154 __driver_attach_async_helper+0x4c/0xc0 async_run_entry_fn+0x34/0xe0 process_one_work+0x148/0x290 worker_threa
0x3c/0x154 __driver_attach_async_helper+0x4c/0xc0 async_run_entry_fn+0x34/0xe0 process_one_work+0x148/0x290 worker_thread+0x2c4/0x3e0 kthread+0x118/0x1c0 ret_from_fork+0x10/0x20 The issue was reported on 12th of August and was ignored by author of commits introducing issue for two weeks. Only after complaining author produced a fix which did not work, so if original commits cannot be reliably fixed for 5 weeks, they obviously are buggy and need to be dropped. References: - https://git.kernel.org/stable/c/1e810d81769e16637bcd845ba37fbc1eba5d4bd2 - https://git.kernel.org/stable/c/a699213d4e6ef4286348c6439837990f121e0c03
CVE ID: CVE-2025-40109 State: PUBLISHED Published: 2025-11-09T04:35:59.979Z Last Updated: 2025-11-09T04:35:59.979Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: rng - Ensure set_ent is always present Ensure that set_ent is always set since only drbg provides it. References: - https://git.kernel.org/stable/c/15d6f42da1bb527629d8e1067b1302d58dec9166 - https://git.kernel.org/stable/c/bd903c25b652c331831226cdf56c8179d18e43f4 - https://git.kernel.org/stable/c/17acbcd44fe8dc17dc1072375e76df2d52da6ac8 - https://git.kernel.org/stable/c/ab172f4f42626549b02bada05f09e3f2b0cc26ec - https://git.kernel.org/stable/c/c5c703b50e91dd474
s://git.kernel.org/stable/c/ab172f4f42626549b02bada05f09e3f2b0cc26ec - https://git.kernel.org/stable/c/c5c703b50e91dd4748769f4c5ab50d9ad60be370 - https://git.kernel.org/stable/c/e247a7d138e514a40edda7c4d72c8bd49bb2cad3 - https://git.kernel.org/stable/c/915cb75983bc5e8b80f8a2f25a4af463f7b18c14 - https://git.kernel.org/stable/c/c0d36727bf39bb16ef0a67ed608e279535ebf0da
CVE ID: CVE-2025-40110 State: PUBLISHED Published: 2025-11-12T01:07:24.739Z Last Updated: 2025-11-12T01:07:24.739Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a null-ptr access in the cursor snooper Check that the resource which is converted to a surface exists before trying to use the cursor snooper on it. vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiers because some svga commands accept SVGA3D_INVALID_ID to mean "no surface", unfortunately functions that accept the actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure
actual surfaces as objects might (and in case of the cursor snooper, do not) be able to handle null objects. Make sure that we validate not only the identifier (via the vmw_cmd_res_check) but also check that the actual resource exists before trying to do something with it. Fixes unchecked null-ptr reference in the snooping code. References: - https://git.kernel.org/stable/c/299cfb5a7deabdf9ecd30071755672af0aced5eb - https://git.kernel.org/stable/c/13c9e4ed125e19484234c960efe5ac9c55119523 - https://git.kernel.org/stable/c/b6fca0a07989f361ceda27cb2d09c555d4d4a964 - https://git.kernel.org/stable/c/5ac2c0279053a2c5265d46903432fb26ae2d0da2
CVE ID: CVE-2025-40111 State: PUBLISHED Published: 2025-11-12T01:07:25.203Z Last Updated: 2025-11-12T01:07:25.203Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix Use-after-free in validation Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely. References: - https://git.kernel.org/stable/c/1822e5287b7dfa59d0af966756ebf1dc652b60ee - https://git.kernel.org/stable/c/fb7165e5f3b3b10721ff70553583ad12e90e447a -
/c/1822e5287b7dfa59d0af966756ebf1dc652b60ee - https://git.kernel.org/stable/c/fb7165e5f3b3b10721ff70553583ad12e90e447a - https://git.kernel.org/stable/c/4c918f9d1ccccc0e092f43dcb2d8266f54d7340b - https://git.kernel.org/stable/c/9a8eaca539708ca532747f606d231f70e684e8ca - https://git.kernel.org/stable/c/867bda5d95d36f10da398fd4409e21c7002b2332 - https://git.kernel.org/stable/c/655a2f29bfc21105c80bf8a7d7aafa6eca8b4496 - https://git.kernel.org/stable/c/65608e991c2d771c13404e5c7ae122ac3c3357a4 - https://git.kernel.org/stable/c/dfe1323ab3c8a4dd5625ebfdba44dc47df84512a
CVE ID: CVE-2025-40112 State: PUBLISHED Published: 2025-11-12T10:23:16.690Z Last Updated: 2025-11-12T10:23:16.690Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sparc: fix accurate exception reporting in copy_{from_to}_user for Niagara The referenced commit introduced exception handlers on user-space memory references in copy_from_user and copy_to_user. These handlers return from the respective function and calculate the remaining bytes left to copy using the current register contents. This commit fixes a couple of bad calculations and a broken epilogue in the exception handlers. This will prevent crashes and ensure correct re
ple of bad calculations and a broken epilogue in the exception handlers. This will prevent crashes and ensure correct return values of copy_from_user and copy_to_user in the faulting case. The behaviour of memcpy stays unchanged. References: - https://git.kernel.org/stable/c/05440320ea3e249d5f984918f2bf51210c1a7c03 - https://git.kernel.org/stable/c/7823fc4d8ab5e57f8db7806ff2530c03c166c4bb - https://git.kernel.org/stable/c/37547d8e6eba87507279ee3dfddfd9dc46335454 - https://git.kernel.org/stable/c/a365ee556e45f780ee322b349a06efdad0c1458f - https://git.kernel.org/stable/c/8cdeb5e482d3fdce7e825444b6ca3865e24c0228 - https://git.kernel.org/stable/c/a90ce516a73dbe087f9bf3dbf311301a58d125c6 - https:
b5e482d3fdce7e825444b6ca3865e24c0228 - https://git.kernel.org/stable/c/a90ce516a73dbe087f9bf3dbf311301a58d125c6 - https://git.kernel.org/stable/c/088c5098ec6d6b0396edfbf3dad3e81de8469c1c - https://git.kernel.org/stable/c/0b67c8fc10b13a9090340c5f8a37d308f4e1571c
CVE ID: CVE-2025-40113 State: PUBLISHED Published: 2025-11-12T10:23:16.992Z Last Updated: 2025-11-12T10:23:16.992Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom: pas: Shutdown lite ADSP DTB on X1E The ADSP firmware on X1E has separate firmware binaries for the main firmware and the DTB. The same applies for the "lite" firmware loaded by the boot firmware. When preparing to load the new ADSP firmware we shutdown the lite_pas_id for the main firmware, but we don't shutdown the corresponding lite pas_id for the DTB. The fact that we're leaving it "running" forever becomes obvious if you try to reuse (or just acce
e pas_id for the DTB. The fact that we're leaving it "running" forever becomes obvious if you try to reuse (or just access) the memory region used by the "lite" firmware: The &adsp_boot_mem is accessible, but accessing the &adsp_boot_dtb_mem results in a crash. We don't support reusing the memory regions currently, but nevertheless we should not keep part of the lite firmware running. Fix this by adding the lite_dtb_pas_id and shutting it down as well. We don't have a way to detect if the lite firmware is actually running yet, so ignore the return status of qcom_scm_pas_shutdown() for now. This was already the case before, the assignment to "ret" is not used anywhere. References: - https://g
tdown() for now. This was already the case before, the assignment to "ret" is not used anywhere. References: - https://git.kernel.org/stable/c/ee150acd273aded01a726ce39b1f6128200799e6 - https://git.kernel.org/stable/c/142964960c7c35de5c5f7bdd61c32699de693630