Export limit exceeded: 378145 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (378145 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-72500 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Free SRQ toggle page after firmware teardown Free the toggle page only after firmware teardown completes so that an NQ interrupt arriving during bnxt_qplib_destroy_srq() won't write the toggle values to an already-freed page. Move free_page() after bnxt_qplib_destroy_srq(). | ||||
| CVE-2026-72499 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Free CQ toggle page after firmware teardown Free the toggle page only after firmware teardown completes so that an NQ interrupt arriving during bnxt_qplib_destroy_cq() won't write the toggle value to an already-freed page. Move free_page() after bnxt_qplib_destroy_cq. | ||||
| CVE-2026-72498 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid displaying the kernel pointer While dumping the info on MR using the rdma tool, we dump the mr_hwq which is a kernel pointer. There is no need to expose this value for end user. So avoid it. | ||||
| CVE-2026-72497 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a max slot check for SQ The variable WQE mode must be validated against the maximum slots supported by HW. The max supported value is 64K. Adding a max and min check and fail if user supplied value is more than the max supported and zero. | ||||
| CVE-2026-72496 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Proper rollback if the ioremap fails bnxt_qplib_alloc_dpi returns success even if ioremap fails. Add the proper rollback when the ioremap fails and return -ENOMEM status. | ||||
| CVE-2026-72495 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Avoid repeated requests to allocate WC pages Applications can request multiple WC pages for the same ucontext. As of now, only 1 WC page per ucontext is supported. Add a lock to avoid concurrent access and a check to fail repeated requests. Also, if the mmap entry insert fails for the WC, free the Doorbell page index mapped for the WC page. | ||||
| CVE-2026-72494 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Replace waitqueue and flag with completion The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done. An earlier patch by Gui-Dong Han <[email protected]> attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose. | ||||
| CVE-2026-72493 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: serialize netif_running() check in enqueue_to_backlog() Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup(). The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit). Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device. However, this creates a TOCTOU race window. A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed. Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped). | ||||
| CVE-2026-72492 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix use-after-free in same_client_has_lease() same_client_has_lease() returns an opinfo pointer from ci->m_op_list after dropping ci->m_lock without taking a reference. smb_grant_oplock() then dereferences that pointer in copy_lease() and when checking breaking_cnt. A concurrent close can remove the old lease from ci->m_op_list and drop the last reference before the caller uses the returned pointer, leading to a use-after-free. Take a reference when same_client_has_lease() selects an existing lease, drop any previous match while scanning, and release the returned reference in smb_grant_oplock() after copying the lease state. | ||||
| CVE-2026-72491 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/9p: fix race condition on rdma->state in trans_rdma.c The rdma->state field is modified without holding req_lock in both recv_done() and p9_cm_event_handler(), while rdma_request() accesses the same field under the req_lock spinlock. This inconsistent locking creates a race condition: - recv_done() running in softirq completion context sets rdma->state = P9_RDMA_FLUSHING without acquiring req_lock - p9_cm_event_handler() modifies rdma->state at multiple points (ADDR_RESOLVED, ROUTE_RESOLVED, ESTABLISHED, CLOSED) without req_lock - rdma_request() uses spin_lock_irqsave(&rdma->req_lock, flags) to protect the read-modify-write of rdma->state The race can cause lost state transitions: recv_done() or the CM event handler could set state to FLUSHING/CLOSED while rdma_request() is concurrently checking or modifying state under the lock, leading to the FLUSHING transition being silently overwritten by CLOSING. This corrupts the connection state machine and can cause use-after-free on RDMA request objects during teardown. Fix by adding req_lock protection to all rdma->state modifications in recv_done() and p9_cm_event_handler(), matching the pattern already used in rdma_request(). Use spin_lock_irqsave/spin_unlock_irqrestore in the CM event handler since it can race with recv_done() which runs in softirq context. Tested with a kernel module that races two threads (simulating rdma_request and recv_done/CM handler) on rdma->state with proper locking: 5.5M+ FLUSHING writes over 27M iterations with 0 lost transitions. | ||||
| CVE-2026-72490 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: staging: rtl8723bs: fix stainfo check in rtw_aes_decrypt The null-pointer-guard was incorrect, returning _FAIL on valid pointer. Invert the guard, so it returns _FAIL on invalid pointer. | ||||
| CVE-2026-72489 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: staging: nvec: fix use-after-free in nvec_rx_completed() In nvec_rx_completed(), when an incomplete RX transfer is detected, nvec_msg_free() is called to return the message back to the pool by clearing its 'used' atomic flag. Immediately after this, the code accesses nvec->rx->data[0] to check the message type. Since nvec_msg_free() marks the pool slot as available via atomic_set(), any concurrent or subsequent call to nvec_msg_alloc() could claim that same slot and overwrite its data[] array. Reading nvec->rx->data[0] after freeing the message is therefore a use-after-free. Fix this by saving the message type byte before calling nvec_msg_free(), then using the saved value for the battery quirk check. | ||||
| CVE-2026-72488 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: soundwire: fix bug in sdw_add_element_group_count found by syzkaller The original implementation caused an out-of-bounds memory access in the sdw_add_element_group_count for-loop when i == num. for (i = 0; i <= num; i++) { if (rate == group->rates[i] && lane == group->lanes[i]) ... To fix this error, the function now checks for existing rate/lane entries in the group(a function parameter) using a for-loop before adding them. No functional changes apart from this fix. | ||||
| CVE-2026-72487 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: PCI: Check ROM header and data structure addr before accessing We meet a crash when running stress-ng on x86_64 machine: BUG: unable to handle page fault for address: ffa0000007f40000 RIP: 0010:pci_get_rom_size+0x52/0x220 Call Trace: <TASK> pci_map_rom+0x80/0x130 pci_read_rom+0x4b/0xe0 kernfs_file_read_iter+0x96/0x180 vfs_read+0x1b1/0x300 Our analysis reveals that the ROM space's start address is 0xffa0000007f30000, and size is 0x10000. Because of broken ROM space, before calling readl(pds), the pds's value is 0xffa0000007f3ffff, which is already pointed to the ROM space end, invoking readl() would read 4 bytes therefore cause an out-of-bounds access and trigger a crash. Fix this by adding image header and data structure checking. We also found another crash on arm64 machine: Unable to handle kernel paging request at virtual address ffff8000dd1393ff Mem abort info: ESR = 0x0000000096000021 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x21: alignment fault The call trace is the same with x86_64, but the crash reason is that the data structure addr is not aligned with 4, and arm64 machine report "alignment fault". Fix this by adding alignment checking. [bhelgaas: shorten function names, wrap comments] | ||||
| CVE-2026-72486 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: mailbox: mtk-adsp: fix UAF during device teardown When the SOF audio driver fails to initialize (e.g. firmware boot timeout), its devres unwind frees the snd_sof_dev object that the mailbox client (mtk-adsp-ipc) reaches via chan->cl->rx_callback. The mtk-adsp-mailbox shutdown clears the mailbox command registers but leaves the IRQ line unmasked, so a late interrupt can still queue a threaded handler after mbox_free_channel() had cleared chan->cl, and mbox_chan_received_data() would then trigger UAF: BUG: KASAN: slab-use-after-free in sof_ipc3_validate_fw_version sof_ipc3_validate_fw_version sof_ipc3_do_rx_work sof_ipc3_rx_msg mt8196_dsp_handle_request mtk_adsp_ipc_recv mbox_chan_received_data mtk_adsp_mbox_isr irq_thread_fn Freed by task ...: kfree devres_release_all really_probe ... (sof-audio-of-mt8196 probe failure) The crash was observed roughly three seconds after the failed probe. disable_irq() in shutdown and enable_irq() in startup. disable_irq() also waits for any in-flight interrupts, so by the time mbox_free_channel() proceeds to clear chan->cl no rx_callback can run. In addition, request the IRQ with IRQF_NO_AUTOEN so it stays masked between probe and the first client bind — otherwise an early interrupt can crash on chan->cl == NULL in mbox_chan_received_data(). | ||||
| CVE-2026-72485 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: coresight: platform: defer connection counter increment until alloc succeeds coresight_add_out_conn() increments nr_outconns before calling devm_krealloc_array() and again before devm_kmalloc(). If either allocation fails, the counter is already bumped while the corresponding array entry is NULL or uninitialized garbage. coresight_add_in_conn() has the same problem with nr_inconns and devm_krealloc_array(). In both cases the probe returns -ENOMEM, which causes coresight_get_platform_data() to call coresight_release_platform_data() for cleanup. That function iterates up to nr_outconns (or nr_inconns) entries and dereferences each pointer unconditionally, hitting the NULL or garbage entry and panicking instead of failing gracefully. Fix by moving the counter increments to after all allocations succeed, so the struct is always consistent on any error path. | ||||
| CVE-2026-72484 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: staging: most: video: avoid double free on video register failure comp_register_videodev() allocates a video_device with video_device_alloc() and releases it if video_register_device() fails. This can double free the video_device when __video_register_device() reaches device_register() and that call fails: video_register_device() -> __video_register_device() -> device_register() fails -> put_device(&vdev->dev) -> v4l2_device_release() -> vdev->release(vdev) -> video_device_release(vdev) comp_register_videodev() -> video_device_release(mdev->vdev) Use video_device_release_empty() while registering the device so that registration failure paths do not free mdev->vdev through vdev->release(). comp_register_videodev() then releases mdev->vdev exactly once on failure. Restore video_device_release() after successful registration so the registered device keeps its normal lifetime handling. This issue was found by a static analysis tool I am developing. | ||||
| CVE-2026-72483 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: usb: host: max3421: Fix shift-out-of-bounds in max3421_hub_control() The `max3421_hub_control()` function handles USB hub class requests to the virtual root hub. In the `default` branches of both the `ClearPortFeature` and `SetPortFeature` switch statements, it modifies `max3421_hcd->port_status` by left shifting 1 by the request's `value` parameter. However, it does not validate whether this shift will exceed the width of `port_status`. So if a malicious userspace task with access to the root hub via /dev/bus/usb/.../001 issues a USBDEVFS_CONTROL ioctl with `wValue` greater than or equal to 32, the left shift operation invokes shift-out-of-bounds undefined behavior. This results in arbitrary bit corruption of `port_status`, including the normally-immutable change bits, which can bypass internal state checks and confuse the hub status. Fix this by rejecting requests whose `value` exceeds the shift width before performing the shift. This issue was found using a KLEE-based symbolic execution tool for kernel drivers that I'm currently developing. | ||||
| CVE-2026-72482 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: gpib: fix double decrement of descriptor_busy in command_ioctl() commit d1857f8296dc ("gpib: fix use-after-free in IO ioctl handlers") introduced a descriptor_busy reference counter to pin struct gpib_descriptor across IO ioctl operations. In command_ioctl(), the error path inside the loop decrements descriptor_busy and breaks, but execution then falls through to the unconditional decrement after the loop, underflowing the counter to -1. This re-enables the use-after-free that the original fix was meant to prevent: a concurrent close_dev_ioctl() sees descriptor_busy == 0 on an actively-used descriptor and frees it. Remove the early decrement from the error path. The post-loop decrement already handles all exit paths, matching the correct pattern used in read_ioctl() and write_ioctl(). | ||||
| CVE-2026-72481 | 1 Linux | 1 Linux Kernel | 2026-08-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iio: magnetometer: ak8975: fix potential kernel stack memory leak Currently in the AK8975 driver there are four instances where potential uninitialized kernel stack memory leaks can occur. If i2c_smbus_read_i2c_block_data_or_emulated() returns a value less than the size of the buffer, uninitialized bytes are retained in the buffer and later the buffer is passed on to IIO buffers, potentially leaking memory to userspace. Fix this by adding checks whether the return value of the function is equal to the size of the buffer and subsequently if the value is lesser than zero to distinguish from a returned error code. | ||||