CyberAlerts is shutting down on June 30th, 2025. Thank you for your support!

Threat and Vulnerability Intelligence Database

Example Searches:

CVE-2025-37889	PCI/MSI: Handle the NOMASK flag correctly for all PCI/MSI backends Description: In the Linux kernel, the following vulnerability has been resolved: PCI/MSI: Handle the NOMASK flag correctly for all PCI/MSI backends The conversion of the XEN specific global variable pci_msi_ignore_mask to a MSI domain flag, missed the facts that: 1) Legacy architectures do not provide a interrupt domain 2) Parent MSI domains do not necessarily have a domain info attached Both cases result in an unconditional NULL pointer dereference. This was unfortunatly missed in review and testing revealed it late. Cure this by using the existing pci_msi_domain_supports() helper, which handles all possible cases correctly. EPSS Score: 0.03% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37888	net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table() Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix null-ptr-deref in mlx5_create_{inner_,}ttc_table() Add NULL check for mlx5_get_flow_namespace() returns in mlx5_create_inner_ttc_table() and mlx5_create_ttc_table() to prevent NULL pointer dereference. EPSS Score: 0.02% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37887	pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result Description: In the Linux kernel, the following vulnerability has been resolved: pds_core: handle unsupported PDS_CORE_CMD_FW_CONTROL result If the FW doesn't support the PDS_CORE_CMD_FW_CONTROL command the driver might at the least print garbage and at the worst crash when the user runs the "devlink dev info" devlink command. This happens because the stack variable fw_list is not 0 initialized which results in fw_list.num_fw_slots being a garbage value from the stack. Then the driver tries to access fw_list.fw_names[i] with i >= ARRAY_SIZE and runs off the end of the array. Fix this by initializing the fw_list and by not failing completely if the devcmd fails because other useful information is printed via devlink dev info even if the devcmd fails. EPSS Score: 0.02% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37886	pds_core: make wait_context part of q_info Description: In the Linux kernel, the following vulnerability has been resolved: pds_core: make wait_context part of q_info Make the wait_context a full part of the q_info struct rather than a stack variable that goes away after pdsc_adminq_post() is done so that the context is still available after the wait loop has given up. There was a case where a slow development firmware caused the adminq request to time out, but then later the FW finally finished the request and sent the interrupt. The handler tried to complete_all() the completion context that had been created on the stack in pdsc_adminq_post() but no longer existed. This caused bad pointer usage, kernel crashes, and much wailing and gnashing of teeth. EPSS Score: 0.02% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37885	KVM: x86: Reset IRTE to host control if new route isn't postable Description: In the Linux kernel, the following vulnerability has been resolved: KVM: x86: Reset IRTE to host control if new route isn't postable Restore an IRTE back to host control (remapped or posted MSI mode) if the new GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU. The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed. EPSS Score: 0.03% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37884	bpf: Fix deadlock between rcu_tasks_trace and event_mutex. Description: In the Linux kernel, the following vulnerability has been resolved: bpf: Fix deadlock between rcu_tasks_trace and event_mutex. Fix the following deadlock: CPU A _free_event() perf_kprobe_destroy() mutex_lock(&event_mutex) perf_trace_event_unreg() synchronize_rcu_tasks_trace() There are several paths where _free_event() grabs event_mutex and calls sync_rcu_tasks_trace. Above is one such case. CPU B bpf_prog_test_run_syscall() rcu_read_lock_trace() bpf_prog_run_pin_on_cpu() bpf_prog_load() bpf_tracing_func_proto() trace_set_clr_event() mutex_lock(&event_mutex) Delegate trace_set_clr_event() to workqueue to avoid such lock dependency. EPSS Score: 0.02% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37883	s390/sclp: Add check for get_zeroed_page() Description: In the Linux kernel, the following vulnerability has been resolved: s390/sclp: Add check for get_zeroed_page() Add check for the return value of get_zeroed_page() in sclp_console_init() to prevent null pointer dereference. Furthermore, to solve the memory leak caused by the loop allocation, add a free helper to do the free job. EPSS Score: 0.03% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37882	usb: xhci: Fix isochronous Ring Underrun/Overrun event handling Description: In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Fix isochronous Ring Underrun/Overrun event handling The TRB pointer of these events points at enqueue at the time of error occurrence on xHCI 1.1+ HCs or it's NULL on older ones. By the time we are handling the event, a new TD may be queued at this ring position. I can trigger this race by rising interrupt moderation to increase IRQ handling delay. Similar delay may occur naturally due to system load. If this ever happens after a Missed Service Error, missed TDs will be skipped and the new TD processed as if it matched the event. It could be given back prematurely, risking data loss or buffer UAF by the xHC. Don't complete TDs on xrun events and don't warn if queued TDs don't match the event's TRB pointer, which can be NULL or a link/no-op TRB. Don't warn if there are no queued TDs at all. Now that it's safe, also handle xrun events if the skip flag is clear. This ensures completion of any TD stuck in 'error mid TD' state right before the xrun event, which could happen if a driver submits a finite number of URBs to a buggy HC and then an error occurs on the last TD. EPSS Score: 0.02% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37881	usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() Description: In the Linux kernel, the following vulnerability has been resolved: usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev() The variable d->name, returned by devm_kasprintf(), could be NULL. A pointer check is added to prevent potential NULL pointer dereference. This is similar to the fix in commit 3027e7b15b02 ("ice: Fix some null pointer dereference issues in ice_ptp.c"). This issue is found by our static analysis tool EPSS Score: 0.04% Source: CVE May 9th, 2025 (about 2 months ago)
CVE-2025-37880	um: work around sched_yield not yielding in time-travel mode Description: In the Linux kernel, the following vulnerability has been resolved: um: work around sched_yield not yielding in time-travel mode sched_yield by a userspace may not actually cause scheduling in time-travel mode as no time has passed. In the case seen it appears to be a badly implemented userspace spinlock in ASAN. Unfortunately, with time-travel it causes an extreme slowdown or even deadlock depending on the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS). Work around it by accounting time to the process whenever it executes a sched_yield syscall. EPSS Score: 0.02% Source: CVE May 9th, 2025 (about 2 months ago)