Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
r_on [bluetooth] Call trace: usb_driver_claim_interface btusb_mtk_claim_iso_intf btusb_mtk_setup hci_dev_open_sync hci_power_on process_scheduled_works worker_thread kthread With the above call trace the device lock hasn't been claimed. Claim it. Without this fix, we'd sometimes see the error "Failed to claim iso interface". Sometimes we'd even see worse errors, like a NULL pointer dereference (where `intf->dev.driver` was NULL) with a trace like: Call trace: usb_suspend_both usb_runtime_suspend __rpm_callback rpm_suspend pm_runtime_work process_scheduled_works Both errors appear to be fixed with the proper locking. References: - https://git.kernel.org/stable/c/930e1790b99e5839e1af69d2f7fd80
appear to be fixed with the proper locking. References: - https://git.kernel.org/stable/c/930e1790b99e5839e1af69d2f7fd808f1fba2df9 - https://git.kernel.org/stable/c/4194766ec8756f4f654d595ae49962acbac49490 - https://git.kernel.org/stable/c/e9087e828827e5a5c85e124ce77503f2b81c3491
CVE ID: CVE-2025-21828 State: PUBLISHED Published: 2025-03-06T16:04:33.641Z Last Updated: 2025-05-04T07:22:00.907Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't flush non-uploaded STAs If STA state is pre-moved to AUTHORIZED (such as in IBSS scenarios) and insertion fails, the station is freed. In this case, the driver never knew about the station, so trying to flush it is unexpected and may crash. Check if the sta was uploaded to the driver before and fix this. References: - https://git.kernel.org/stable/c/cf21ef3d430847ba864bbc9b2774fffcc03ce321 - https://git.kernel.org/stable/c/cd10b7fcb95a6a86c67adc54
.kernel.org/stable/c/cf21ef3d430847ba864bbc9b2774fffcc03ce321 - https://git.kernel.org/stable/c/cd10b7fcb95a6a86c67adc54304c59a578ab16af - https://git.kernel.org/stable/c/9efb5531271fa7ebae993b2a33a705d9947c7ce6 - https://git.kernel.org/stable/c/aa3ce3f8fafa0b8fb062f28024855ea8cb3f3450
CVE ID: CVE-2025-21829 State: PUBLISHED Published: 2025-03-06T16:08:09.054Z Last Updated: 2025-11-03T20:59:58.958Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Fix the warning "__rxe_cleanup+0x12c/0x170 [rdma_rxe]" The Call Trace is as below: " <TASK> ? show_regs.cold+0x1a/0x1f ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __warn+0x84/0xd0 ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? report_bug+0x105/0x180 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x19/0x70 ? asm_exc_invalid_op+0x1b/0x20 ? __rxe_cleanup+0x12c/0x170 [rdma_rxe] ? __rxe_cleanup+0x124/0x170 [rdma_rxe] rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe] ib_destroy_qp_user+0x1
/0x170 [rdma_rxe] ? __rxe_cleanup+0x124/0x170 [rdma_rxe] rxe_destroy_qp.cold+0x24/0x29 [rdma_rxe] ib_destroy_qp_user+0x118/0x190 [ib_core] rdma_destroy_qp.cold+0x43/0x5e [rdma_cm] rtrs_cq_qp_destroy.cold+0x1d/0x2b [rtrs_core] rtrs_srv_close_work.cold+0x1b/0x31 [rtrs_server] process_one_work+0x21d/0x3f0 worker_thread+0x4a/0x3c0 ? process_one_work+0x3f0/0x3f0 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 </TASK> " When too many rdma resources are allocated, rxe needs more time to handle these rdma resources. Sometimes with the current timeout, rxe can not release the rdma resources correctly. Compared with other rdma drivers, a bigger timeout is used. Additio
t, rxe can not release the rdma resources correctly. Compared with other rdma drivers, a bigger timeout is used. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/720653309dd31c8a927ef5d87964578ad544980f - https://git.kernel.org/stable/c/45e567800492088bc52c9abac35524b4d332a8f8 - https://git.kernel.org/stable/c/7a2de8126ed3801f2396720e10a03cd546a3cea1 - https://git.kernel.org/stable/c/a7d15eaecf0d6e13226db629ae2401c8c02683e5 - https://git.kernel.org/stable/c/edc4ef0e0154096d6c0cf5e06af6fc330dbad9d1
CVE ID: CVE-2025-21830 State: PUBLISHED Published: 2025-03-06T16:08:09.894Z Last Updated: 2025-11-03T21:00:01.286Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: landlock: Handle weird files A corrupted filesystem (e.g. bcachefs) might return weird files. Instead of throwing a warning and allowing access to such file, treat them as regular files. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/a1fccf6b72b56343dd4f2d96b008147f9951eebd - https://git.kernel.org/stable/c/7d6121228959ddf44a4b9b6a177384ac7854e2f9 - https://git.kernel.org/stable/c/39bb3d56f1c351e76bb18895d0e73796e653d5c
ble/c/7d6121228959ddf44a4b9b6a177384ac7854e2f9 - https://git.kernel.org/stable/c/39bb3d56f1c351e76bb18895d0e73796e653d5c1 - https://git.kernel.org/stable/c/2569e65d2eb6ac1afe6cb6dfae476afee8b6771a - https://git.kernel.org/stable/c/0fde195a373ab1267e60baa9e1a703a97e7464cd - https://git.kernel.org/stable/c/49440290a0935f428a1e43a5ac8dc275a647ff80
CVE ID: CVE-2025-21831 State: PUBLISHED Published: 2025-03-06T16:22:33.443Z Last Updated: 2025-05-04T07:22:04.294Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1 commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the policy that all PCIe ports are allowed to use D3. When the system is suspended if the port is not power manageable by the platform and won't be used for wakeup via a PME this sets up the policy for these ports to go into D3hot. This policy generally makes sense from an OSPM perspective but it leads to problems with wakeup from sus
go into D3hot. This policy generally makes sense from an OSPM perspective but it leads to problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a specific old BIOS. This manifests as a system hang. On the affected Device + BIOS combination, add a quirk for the root port of the problematic controller to ensure that these root ports are not put into D3hot at suspend. This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com but with the added condition both in the documentation and in the code to apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only the affected root ports. References: - https://git.kernel.org/
TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only the affected root ports. References: - https://git.kernel.org/stable/c/8852e056e297df1d8635ee7504e780d3184e45d0 - https://git.kernel.org/stable/c/5ee3dd6e59b834e4d66e8b16fc684749ee40a257 - https://git.kernel.org/stable/c/a78dfe50fffe6058afed2bb04c50c2c9a16664ee - https://git.kernel.org/stable/c/b1049f2d68693c80a576c4578d96774a68df2bad
CVE ID: CVE-2025-21832 State: PUBLISHED Published: 2025-03-06T16:22:34.125Z Last Updated: 2025-11-03T21:00:04.401Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: block: don't revert iter for -EIOCBQUEUED blkdev_read_iter() has a few odd checks, like gating the position and count adjustment on whether or not the result is bigger-than-or-equal to zero (where bigger than makes more sense), and not checking the return value of blkdev_direct_IO() before doing an iov_iter_revert(). The latter can lead to attempting to revert with a negative value, which when passed to iov_iter_revert() as an unsigned value will lead to throwing a WAR
to revert with a negative value, which when passed to iov_iter_revert() as an unsigned value will lead to throwing a WARN_ON() because unroll is bigger than MAX_RW_COUNT. Be sane and don't revert for -EIOCBQUEUED, like what is done in other spots. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/6c26619effb1b4cb7d20b4e666ab8f71f6a53ccb - https://git.kernel.org/stable/c/84671b0630ccb46ae9f1f99a45c7d63ffcd6a474 - https://git.kernel.org/stable/c/68f16d3034a06661245ecd22f0d586a8b4e7c473 - https://git.kernel.org/stable/c/a58f136bad29f9ae721a29d98c042fddbee22f77 - https://git.kernel.org/stable/c/b13ee668e8280ca5b07f8ce2846b9957a8a10853
CVE ID: CVE-2025-21833 State: PUBLISHED Published: 2025-03-06T16:22:34.798Z Last Updated: 2025-11-02T13:30:22.042Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid use of NULL after WARN_ON_ONCE There is a WARN_ON_ONCE to catch an unlikely situation when domain_remove_dev_pasid can't find the `pasid`. In case it nevertheless happens we must avoid using a NULL pointer. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/68ec78beb4a3fb0877cbaaf49758c85410c05977 - https://git.kernel.org/stable/c/df96876be3b064aefc493f760e0639765d13ed0d - https://git.kernel.org/stable/c/6
410c05977 - https://git.kernel.org/stable/c/df96876be3b064aefc493f760e0639765d13ed0d - https://git.kernel.org/stable/c/60f030f7418d3f1d94f2fb207fe3080e1844630b
CVE ID: CVE-2025-21834 State: PUBLISHED Published: 2025-03-06T16:22:35.490Z Last Updated: 2025-05-04T07:22:07.345Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: seccomp: passthrough uretprobe systemcall without filtering When attaching uretprobes to processes running inside docker, the attached process is segfaulted when encountering the retprobe. The reason is that now that uretprobe is a system call the default seccomp filters in docker block it as they only allow a specific set of known syscalls. This is true for other userspace applications which use seccomp to control their syscall surface. Since uretprobe is a "kernel im
rue for other userspace applications which use seccomp to control their syscall surface. Since uretprobe is a "kernel implementation detail" system call which is not used by userspace application code directly, it is impractical and there's very little point in forcing all userspace applications to explicitly allow it in order to avoid crashing tracked processes. Pass this systemcall through seccomp without depending on configuration. Note: uretprobe is currently only x86_64 and isn't expected to ever be supported in i386. [kees: minimized changes for easier backporting, tweaked commit log] References: - https://git.kernel.org/stable/c/5a262628f4cf2437d863fe41f9d427177b87664c - https://git.k
eaked commit log] References: - https://git.kernel.org/stable/c/5a262628f4cf2437d863fe41f9d427177b87664c - https://git.kernel.org/stable/c/fa80018aa5be10c35e9fa896b7b4061a8dce3eed - https://git.kernel.org/stable/c/cf6cb56ef24410fb5308f9655087f1eddf4452e6
CVE ID: CVE-2025-21835 State: PUBLISHED Published: 2025-03-07T09:09:55.320Z Last Updated: 2025-11-03T21:00:07.684Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_midi: fix MIDI Streaming descriptor lengths While the MIDI jacks are configured correctly, and the MIDIStreaming endpoint descriptors are filled with the correct information, bNumEmbMIDIJack and bLength are set incorrectly in these descriptors. This does not matter when the numbers of in and out ports are equal, but when they differ the host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is
host will receive broken descriptors with uninitialized stack memory leaking into the descriptor for whichever value is smaller. The precise meaning of "in" and "out" in the port counts is not clearly defined and can be confusing. But elsewhere the driver consistently uses this to match the USB meaning of IN and OUT viewed from the host, so that "in" ports send data to the host and "out" ports receive data from it. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/3a983390d14e8498f303fc5cb23ab7d696b815db - https://git.kernel.org/stable/c/9f36a89dcb78cb7e37f487b04a16396ac18c0636 - https://git.kernel.org/stable/c/d8e86700c8a8cf415e300a0921acd6a8f
rg/stable/c/9f36a89dcb78cb7e37f487b04a16396ac18c0636 - https://git.kernel.org/stable/c/d8e86700c8a8cf415e300a0921acd6a8f9b494f8 - https://git.kernel.org/stable/c/9f6860a9c11301b052225ca8825f8d2b1a5825bf - https://git.kernel.org/stable/c/6ae6dee9f005a2f3b739b85abb6f14a0935699e0 - https://git.kernel.org/stable/c/6b16761a928796e4b49e89a0b1ac284155172726 - https://git.kernel.org/stable/c/a2d0694e1f111379c1efdf439dadd3cfd959fe9d - https://git.kernel.org/stable/c/da1668997052ed1cb00322e1f3b63702615c9429
CVE ID: CVE-2025-21836 State: PUBLISHED Published: 2025-03-07T09:09:56.127Z Last Updated: 2025-05-04T07:22:09.559Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: io_uring/kbuf: reallocate buf lists on upgrade IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy selected buffer and has been emptied. It violates the requirement that most of the field should stay stable after publish. Always reallocate it instead. References: - https://git.kernel.org/stable/c/146a185f6c05ee263db715f860620606303c4633 - https://git.kernel.org/stable/c/7d0dc28dae836caf7645fef62a10befc624dd17b - https://git.ker
e263db715f860620606303c4633 - https://git.kernel.org/stable/c/7d0dc28dae836caf7645fef62a10befc624dd17b - https://git.kernel.org/stable/c/2a5febbef40ce968e295a7aeaa5d5cbd9e3e5ad4 - https://git.kernel.org/stable/c/8802766324e1f5d414a81ac43365c20142e85603
CVE ID: CVE-2025-21837 State: REJECTED Published: 2025-03-07T09:09:56.827Z Last Updated: 2025-05-20T13:53:34.359Z Description: No description available.
CVE ID: CVE-2025-21838 State: PUBLISHED Published: 2025-03-07T09:09:57.515Z Last Updated: 2025-11-03T19:37:56.459Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: core: flush gadget workqueue after device removal device_del() can lead to new work being scheduled in gadget->work workqueue. This is observed, for example, with the dwc3 driver with the following call stack: device_del() gadget_unbind_driver() usb_gadget_disconnect_locked() dwc3_gadget_pullup() dwc3_gadget_soft_disconnect() usb_gadget_set_state() schedule_work(&gadget->work) Move flush_work() after device_del() to ensure the workqueue is cleaned up. Addi
et_state() schedule_work(&gadget->work) Move flush_work() after device_del() to ensure the workqueue is cleaned up. Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/e3bc1a9a67ce33a2e761e6e7b7c2afc6cb9b7266 - https://git.kernel.org/stable/c/859cb45aefa6de823b2fa7f229fe6d9562c9f3b7 - https://git.kernel.org/stable/c/f894448f3904d7ad66fecef8f01fe0172629e091 - https://git.kernel.org/stable/c/97695b5a1b5467a4f91194db12160f56da445dfe - https://git.kernel.org/stable/c/399a45e5237ca14037120b1b895bd38a3b4492ea
CVE ID: CVE-2025-21839 State: PUBLISHED Published: 2025-03-07T09:09:58.220Z Last Updated: 2025-11-03T19:37:57.827Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Load DR6 with guest value only before entering .vcpu_run() loop Move the conditional loading of hardware DR6 with the guest's DR6 value out of the core .vcpu_run() loop to fix a bug where KVM can load hardware with a stale vcpu->arch.dr6. When the guest accesses a DR and host userspace isn't debugging the guest, KVM disables DR interception and loads the guest's values into hardware on VM-Enter and saves them on VM-Exit. This allows the guest to access DRs at
and loads the guest's values into hardware on VM-Enter and saves them on VM-Exit. This allows the guest to access DRs at will, e.g. so that a sequence of DR accesses to configure a breakpoint only generates one VM-Exit. For DR0-DR3, the logic/behavior is identical between VMX and SVM, and also identical between KVM_DEBUGREG_BP_ENABLED (userspace debugging the guest) and KVM_DEBUGREG_WONT_EXIT (guest using DRs), and so KVM handles loading DR0-DR3 in common code, _outside_ of the core kvm_x86_ops.vcpu_run() loop. But for DR6, the guest's value doesn't need to be loaded into hardware for KVM_DEBUGREG_BP_ENABLED, and SVM provides a dedicated VMCB field whereas VMX requires software to manually l
ardware for KVM_DEBUGREG_BP_ENABLED, and SVM provides a dedicated VMCB field whereas VMX requires software to manually load the guest value, and so loading the guest's value into DR6 is handled by {svm,vmx}_vcpu_run(), i.e. is done _inside_ the core run loop. Unfortunately, saving the guest values on VM-Exit is initiated by common x86, again outside of the core run loop. If the guest modifies DR6 (in hardware, when DR interception is disabled), and then the next VM-Exit is a fastpath VM-Exit, KVM will reload hardware DR6 with vcpu->arch.dr6 and clobber the guest's actual value. The bug shows up primarily with nested VMX because KVM handles the VMX preemption timer in the fastpath, and the wi
lue. The bug shows up primarily with nested VMX because KVM handles the VMX preemption timer in the fastpath, and the window between hardware DR6 being modified (in guest context) and DR6 being read by guest software is orders of magnitude larger in a nested setup. E.g. in non-nested, the VMX preemption timer would need to fire precisely between #DB injection and the #DB handler's read of DR6, whereas with a KVM-on-KVM setup, the window where hardware DR6 is "dirty" extends all the way from L1 writing DR6 to VMRESUME (in L1). L1's view: ========== <L1 disables DR interception> CPU 0/KVM-7289 [023] d.... 2925.640961: kvm_entry: vcpu 0 A: L1 Writes DR6 CPU 0/KVM-7289 [023] d.... 2925.640963: <
on> CPU 0/KVM-7289 [023] d.... 2925.640961: kvm_entry: vcpu 0 A: L1 Writes DR6 CPU 0/KVM-7289 [023] d.... 2925.640963: <hack>: Set DRs, DR6 = 0xffff0ff1 B: CPU 0/KVM-7289 [023] d.... 2925.640967: kvm_exit: vcpu 0 reason EXTERNAL_INTERRUPT intr_info 0x800000ec D: L1 reads DR6, arch.dr6 = 0 CPU 0/KVM-7289 [023] d.... 2925.640969: <hack>: Sync DRs, DR6 = 0xffff0ff0 CPU 0/KVM-7289 [023] d.... 2925.640976: kvm_entry: vcpu 0 L2 reads DR6, L1 disables DR interception CPU 0/KVM-7289 [023] d.... 2925.640980: kvm_exit: vcpu 0 reason DR_ACCESS info1 0x0000000000000216 CPU 0/KVM-7289 [023] d.... 2925.640983: kvm_entry: vcpu 0 CPU 0/KVM-7289 [023] d.... 2925.640983: <hack>: Set DRs, DR6 = 0xffff0ff0 L2 d
023] d.... 2925.640983: kvm_entry: vcpu 0 CPU 0/KVM-7289 [023] d.... 2925.640983: <hack>: Set DRs, DR6 = 0xffff0ff0 L2 detects failure CPU 0/KVM-7289 [023] d.... 2925.640987: kvm_exit: vcpu 0 reason HLT L1 reads DR6 (confirms failure) CPU 0/KVM-7289 [023] d.... 2925.640990: <hack>: Sync DRs, DR6 = 0xffff0ff0 L0's view: ========== L2 reads DR6, arch.dr6 = 0 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_exit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit: vcpu 23 reason DR_ACCESS info1 0x0000000000000216 L2 => L1 nested VM-Exit CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit_inject: reason: DR_ACCESS ext_inf1: 0x000000000
ested VM-Exit CPU 23/KVM-5046 [001] ..... 3410.005610: kvm_nested_vmexit_inject: reason: DR_ACCESS ext_inf1: 0x0000000000000216 CPU 23/KVM-5046 [001] d.... 3410.005610: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_exit: vcpu 23 reason VMREAD CPU 23/KVM-5046 [001] d.... 3410.005611: kvm_entry: vcpu 23 CPU 23/KVM-5046 [001] d.... 3410. ---truncated--- Additional Analyst Notes: - CVE Program Container: References: - https://git.kernel.org/stable/c/9efb2b99b96c86664bbdbdd2cdb354ac9627eb20 - https://git.kernel.org/stable/c/93eeb6df1605b3a24f38afdba7ab903ba6b64133 - https://git.kernel.org/stable/c/a1723e9c53fe6431415be19302a56543daf503f5 - https://git.kernel.org/stable/c/4eb063d
133 - https://git.kernel.org/stable/c/a1723e9c53fe6431415be19302a56543daf503f5 - https://git.kernel.org/stable/c/4eb063de686bfcdfd03a8c801d1bbe87d2d5eb55 - https://git.kernel.org/stable/c/d456de38d9eb753a4e9fde053c18d4ef8e485339 - https://git.kernel.org/stable/c/c2fee09fc167c74a64adb08656cb993ea475197e
CVE ID: CVE-2025-21840 State: PUBLISHED Published: 2025-03-07T09:09:58.907Z Last Updated: 2025-05-04T07:22:19.691Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: thermal/netlink: Prevent userspace segmentation fault by adjusting UAPI header The intel-lpmd tool [1], which uses the THERMAL_GENL_ATTR_CPU_CAPABILITY attribute to receive HFI events from kernel space, encounters a segmentation fault after commit 1773572863c4 ("thermal: netlink: Add the commands and the events for the thresholds"). The issue arises because the THERMAL_GENL_ATTR_CPU_CAPABILITY raw value was changed while intel_lpmd still uses the old value. Although in
ecause the THERMAL_GENL_ATTR_CPU_CAPABILITY raw value was changed while intel_lpmd still uses the old value. Although intel_lpmd can be updated to check the THERMAL_GENL_VERSION and use the appropriate THERMAL_GENL_ATTR_CPU_CAPABILITY value, the commit itself is questionable. The commit introduced a new element in the middle of enum thermal_genl_attr, which affects many existing attributes and introduces potential risks and unnecessary maintenance burdens for userspace thermal netlink event users. Solve the issue by moving the newly introduced THERMAL_GENL_ATTR_TZ_PREV_TEMP attribute to the end of the enum thermal_genl_attr. This ensures that all existing thermal generic netlink attributes r
attribute to the end of the enum thermal_genl_attr. This ensures that all existing thermal generic netlink attributes remain unaffected. [ rjw: Subject edits ] References: - https://git.kernel.org/stable/c/3a4ca365c51729143a2cab693cd40fe0bb585ef0 - https://git.kernel.org/stable/c/c195b9c6ab9c383d7aa3f4a65879b3ca90cb378b
CVE ID: CVE-2025-21841 State: PUBLISHED Published: 2025-03-07T09:09:59.587Z Last Updated: 2025-05-04T07:22:20.927Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cpufreq/amd-pstate: Fix cpufreq_policy ref counting amd_pstate_update_limits() takes a cpufreq_policy reference but doesn't decrement the refcount in one of the exit paths, fix that. References: - https://git.kernel.org/stable/c/56e6976793c0fcf1638aa534242408ab4e4ca705 - https://git.kernel.org/stable/c/28e4c515cf644c621800bd97841757fd49891ba4 - https://git.kernel.org/stable/c/3ace20038e19f23fe73259513f1f08d4bf1a3c83
CVE ID: CVE-2025-21842 State: PUBLISHED Published: 2025-03-07T09:10:00.298Z Last Updated: 2025-05-04T07:22:22.023Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: amdkfd: properly free gang_ctx_bo when failed to init user queue The destructor of a gtt bo is declared as void amdgpu_amdkfd_free_gtt_mem(struct amdgpu_device *adev, void **mem_obj); Which takes void** as the second parameter. GCC allows passing void* to the function because void* can be implicitly casted to any other types, so it can pass compiling. However, passing this void* parameter into the function's execution process(which expects void** and dereferencing void
However, passing this void* parameter into the function's execution process(which expects void** and dereferencing void**) will result in errors. References: - https://git.kernel.org/stable/c/ae5ab1c1ae504f622cc1ff48830a9ed48428146d - https://git.kernel.org/stable/c/091a68c58c1bbd2ab7d05d1b32c1306394ec691d - https://git.kernel.org/stable/c/a33f7f9660705fb2ecf3467b2c48965564f392ce
CVE ID: CVE-2025-21843 State: PUBLISHED Published: 2025-03-07T09:10:01.189Z Last Updated: 2025-10-01T19:36:35.324Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/panthor: avoid garbage value in panthor_ioctl_dev_query() 'priorities_info' is uninitialized, and the uninitialized value is copied to user object when calling PANTHOR_UOBJ_SET(). Using memset to initialize 'priorities_info' to avoid this garbage value problem. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/64b95bbc08bacf3e4b05c8604e6a4fec43bb712a - https://git.kernel.org/stable/c/3b32b7f638fe61e9d29290960172f4e360e
/stable/c/64b95bbc08bacf3e4b05c8604e6a4fec43bb712a - https://git.kernel.org/stable/c/3b32b7f638fe61e9d29290960172f4e360e38233