Page 41 of 5912 results (0.005 seconds)

CVSS: 7.8EPSS: 0%CPEs: 6EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ife: Fix metalist update behavior Whenever an ife action replace changes the metalist, instead of replacing the old data on the metalist, the current ife code is appending the new metadata. Aside from being innapropriate behavior, this may lead to an unbounded addition of metadata to the metalist which might cause an out of bounds error when running the encode op: [ 138.423369][ C1] ===========================================... • https://git.kernel.org/stable/c/aa9fd9a325d51fa0b11153b03b8fefff569fa955 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: blktrace: fix __this_cpu_read/write in preemptible context tracing_record_cmdline() internally uses __this_cpu_read() and __this_cpu_write() on the per-CPU variable trace_cmdline_save, and trace_save_cmdline() explicitly asserts preemption is disabled via lockdep_assert_preemption_disabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probe_wakeup_sched_switch() / pr... • https://git.kernel.org/stable/c/7ffbd48d5cab22bcd1120eb2349db1319e2d827a •

CVSS: 7.8EPSS: 0%CPEs: 8EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: nfc: rawsock: cancel tx_work before socket teardown In rawsock_release(), cancel any pending tx_work and purge the write queue before orphaning the socket. rawsock_tx_work runs on the system workqueue and calls nfc_data_exchange which dereferences the NCI device. Without synchronization, tx_work can race with socket and device teardown when a process is killed (e.g. by SIGKILL), leading to use-after-free or leaked references. Set SEND_SHUTD... • https://git.kernel.org/stable/c/23b7869c0fd08d73c9f83a2db88a13312d6198bb •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited). sched: DL de-boosted task PID 22725: REPLENISH flag missing WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8 ... (running_bw underflow) Call trace: dequeue_task_dl+0x15c/0x1f8 (P) dequeue_task+0x80/0x168 deactivate_task+0x24/0x5... • https://git.kernel.org/stable/c/2279f540ea7d05f22d2f0c4224319330228586bc •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: net: phy: register phy led_triggers during probe to avoid AB-BA deadlock There is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and LED_TRIGGER_PHY are enabled: [ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc <-- Trying to get lock "triggers_list_lock" via down_write(&triggers_list_lock); [ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234 [ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c [ 1362.065489] [<... • https://git.kernel.org/stable/c/06f502f57d0d7728f9fa0f157ec5e4111ddb98f6 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: wifi: radiotap: reject radiotap with unknown bits The radiotap parser is currently only used with the radiotap namespace (not with vendor namespaces), but if the undefined field 18 is used, the alignment/size is unknown as well. In this case, iterator->_next_ns_data isn't initialized (it's only set for skipping vendor namespaces), and syzbot points out that we later compare against this uninitialized value. Fix this by moving the rejection ... • https://git.kernel.org/stable/c/33e5a2f776e331dc8a4379b6efb660d38f182d96 •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: net: usb: kalmia: validate USB endpoints The kalmia driver should validate that the device it is probing has the proper number and types of USB endpoints it is expecting before it binds to it. If a malicious device were to not have the same urbs the driver will crash later on when it blindly accesses these endpoints. • https://git.kernel.org/stable/c/d40261236e8e278cb1936cb5e934262971692b10 •

CVSS: -EPSS: 0%CPEs: 4EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X interrupt to the host using a writel(), which generates a PCI posted write transaction. There's no completion for posted writes, so the writel() may return before the PCI write completes. dw_pcie_ep_raise_msix_irq() also unmaps the outbound ATU entry used for the PCI write, so the write races with the unmap. If t... • https://git.kernel.org/stable/c/beb4641a787df79a1423a8789d185b6b78fcbfea •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix deadlock in error path of mcp251x_open The mcp251x_open() function call free_irq() in its error path with the mpc_lock mutex held. But if an interrupt already occurred the interrupt handler will be waiting for the mpc_lock and free_irq() will deadlock waiting for the handler to finish. This issue is similar to the one fixed in commit 7dd9c26bd6cf ("can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open") but... • https://git.kernel.org/stable/c/bf66f3736a945dd4e92d86427276c6eeab0a6c1d •

CVSS: -EPSS: 0%CPEs: 8EXPL: 0

25 Mar 2026 — In the Linux kernel, the following vulnerability has been resolved: drbd: fix "LOGIC BUG" in drbd_al_begin_io_nonblock() Even though we check that we "should" be able to do lc_get_cumulative() while holding the device->al_lock spinlock, it may still fail, if some other code path decided to do lc_try_lock() with bad timing. If that happened, we logged "LOGIC BUG for enr=...", but still did not return an error. The rest of the code now assumed that this request has references for the relevant activity log ext... • https://git.kernel.org/stable/c/08a1ddab6df7d3c7b6341774cb1cf4b21b96a214 •