Updated 10 h ago

Vulnerability database

Every flaw the U.S. government’s cybersecurity agency (CISA) has confirmed attackers are using, plus the new WordPress plugin and theme bugs published each day, sorted by what they mean for a small business. We refresh it twice a day. If you see something your website or office runs, tell us.

1,764exploited flaws on CISA’s list

35added in the last 30 days

456new WordPress flaws this week

390,714entries in the database

18,664 results · page 9 of 374

Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: mtd: core: avoid double-free of OTP NVMEM device If factory OTP setup fails after the userCVE-2026-98834 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mtd: core: avoid double-free of OTP NVMEM device If factory OTP setup fails after the user OTP NVMEM device has been registered, mtd_otp_nvmem_add() unregisters the user device but leaves mtd->otp_user_nvmem set. On an error, the caller unregisters it again. For -EOPNOTSUPP, registration continues and normal teardown unregisters it again. Clear mtd->otp_user_nvmem after unregistering it.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: mtd: core: call _get_device() with the master MTD __get_mtd_device() calls the master's _gCVE-2026-98833 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mtd: core: call _get_device() with the master MTD __get_mtd_device() calls the master's _get_device() callback with mtd, which may be a partition. __put_mtd_device() passes the master. This breaks gluebi partitions because gluebi_get_device() uses container_of() and therefore requires the master MTD. Pass the master to _get_device(), matching _put_device().
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: save IRQ state in blkg_tryget_closest() bio_set_dev() associates the bio with CVE-2026-98832 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: save IRQ state in blkg_tryget_closest() bio_set_dev() associates the bio with a blkg through bio_associate_blkg(). If the blkg lookup misses, blkg_tryget_closest() takes q->queue_lock with spin_lock_irq() and releases it with spin_unlock_irq(), which unconditionally enables local interrupts. Callers may call bio_set_dev() with interrupts already disabled, e.g. dm-thin's pool_map() does so while holding pool->lock taken with spin_lock_irq(). The nested spin_unlock_irq() then enables interrupts while pool->lock is still held, so an I/O completion softirq can run on the same CPU, re-acquire pool->lock (thin_endio(), or overwrite_endio() -> complete_mapping_preparation()) and deadlock. lockdep reports this as inconsistent SOFTIRQ-ON-W to IN-SOFTIRQ-W usage. Commit 3a762de55b4e ("block: save irq state in blkg_lookup_create()") fixed the same problem while the lock lived in blkg_lookup_create(), but commit 9327a865e395 ("blk-cgroup: don't nest queue_lock under rcu in blkg_lookup_create()") moved the locking into blkg_tryget_closest() and reverted it to spin_lock_irq(). Save and restore the caller's IRQ
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: of/overlay: don't leak fragment references when changeset init fails init_overlay_changeseCVE-2026-98831 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: of/overlay: don't leak fragment references when changeset init fails init_overlay_changeset() stores the number of initialized fragments in ovcs->count only on full success. When find_target() or the __symbols__ lookup fails partway through, the target and overlay references taken for the fragments initialized so far are never dropped: free_overlay_changeset() bounds its cleanup loop by ovcs->count, which is still 0. Store the running count on the error path so free_overlay_changeset() puts whatever was set up. The store is guarded by ovcs->fragments because on the allocation-failure path cnt still holds the counting pass total while there is no fragments array; everywhere else cnt only counts fully-initialized fragments.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: validate MIB read length before copying to caller wfx_hif_read_mib() copies repCVE-2026-98830 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: wfx: validate MIB read length before copying to caller wfx_hif_read_mib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed val_len. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation. Replace the dead -ENOMEM check with an active validation that reply->length fits within val_len before the memcpy.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop oversized fragments to avoid extra_len overflow In ieee80211_rx_h_defCVE-2026-98829 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: drop oversized fragments to avoid extra_len overflow In ieee80211_rx_h_defragment(), fragment payloads are accumulated into entry->extra_len as subsequent fragments arrive: entry->extra_len += rx->skb->len; When the final fragment arrives, the head fragment is dequeued, and pskb_expand_head() is called with entry->extra_len to ensure sufficient tailroom for all queued fragments before copying: if (skb_tailroom(rx->skb) < entry->extra_len) { if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len, GFP_ATOMIC))) { ... } } while ((skb = __skb_dequeue(&entry->skb_list))) { skb_put_data(rx->skb, skb->data, skb->len); dev_kfree_skb(skb); } In commit 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned int to u16 in order to reduce structure memory footprint. However, an IEEE 802.11 frame sequence can contain up to 16 fragments (frag numbers 0..15). If a sequence of la
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: reject short WMI command responses ath9k_wmi_rsp_callback() removes the validCVE-2026-98828 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k: reject short WMI command responses ath9k_wmi_rsp_callback() removes the validated WMI header and copies the number of bytes expected by the waiting command into its response buffer. A device response shorter than that expectation can therefore be read beyond the skb payload. Record -EMSGSIZE for a short response, complete the waiter, and return the stored status from the command path. This also prevents callers from consuming stale response bytes as a successful reply.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE __hif_usb_tx() dequeues up to MAXCVE-2026-98827 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE __hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a single tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch by record count but never by cumulative byte length. With large frames (MTU 2304), 20 aggregated frames of 2292 bytes each exceed the allocation (20 * 2296 = 45920 bytes), so the memcpy() in the loop writes up to 13152 bytes past tx_buf->buf before usb_submit_urb(). Peek the queue head and stop before copying any record that would cross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover skbs remain queued and are drained on the next URB completion. The byte bound changes the loop's exit semantics: it can now exit before i == tx_skb_cnt - 1. Stock only finalized tx_buf->len on that last index (len += offset), so an early break would submit a URB holding only the last record's length while every dequeued skb is freed on completion, silently dropping frames. Make tx_buf->len a running total and advance tx_buf->offset per record instead; the stride round_up(nskb->len + 4, 4) is identical to the stock stride when the loop
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: rtc: ac100: Fix clock provider use-after-free on probe failure ac100_rtc_register_clks() rCVE-2026-98826 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: rtc: ac100: Fix clock provider use-after-free on probe failure ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device's managed resources. ac100_rtc_probe() ends with return devm_rtc_register_device(chip->rtc); so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip->clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100_rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100_rtc 0>. The window is narrow, as devm_rtc_register_device() can only
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe() devm_clk_get(&pdev->dev, CVE-2026-98825 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe() devm_clk_get(&pdev->dev, "rtcref")'s return value was passed straight into clk_get_rate() without checking it for an error first, unlike the "rtc" clock a few lines above which is correctly checked with IS_ERR(). clk_get_rate() only guards against a NULL clk, not an error pointer: if (!clk) return 0; ... rate = clk_core_get_rate_recalc(clk->core); so if devm_clk_get() ever returns an error pointer here (for example ERR_PTR(-EPROBE_DEFER), which is the normal, expected outcome if the clkcfg clock-provider this RTC depends on has not registered its clocks yet by the time this driver probes), clk_get_rate() dereferences that error pointer instead of returning 0, crashing instead of letting probe defer. Capture the clock in the existing 'clk' local and check it with IS_ERR() before calling clk_get_rate(), matching the handling already used for the "rtc" clock in this same function.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: validate TX status rate metadata minstrel_ht_tx_status() converts the HT/VCVE-2026-98824 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: validate TX status rate metadata minstrel_ht_tx_status() converts the HT/VHT rate reported in a TX status into a group and rate index and uses those to index the minstrel_ht rate tables. The existing validation only checked that an entry was present and had tries recorded; it did not check that the reported MCS, spatial stream count and bandwidth are representable by the tables, so malformed metadata passed to minstrel_ht_get_stats() or minstrel_ht_ri_get_stats() could be used as an out-of-bounds index. Validate the rate metadata in the common TX status path instead of only in minstrel_ht, since the values are used by more than rate control. The legacy ieee80211_tx_rate array and the rate_info based entries are sanitized in ieee80211_tx_status_ext() and ieee80211_tx_rate_update() before any consumer runs: an entry that does not describe a valid rate for its encoding is dropped. minstrel_ht keeps the checks that depend on its own tables, i.e. the supported number of spatial streams, the MCS group size and the supported bandwidths. This does not take away the driver's responsibility to report sa
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: preserve hidden-group beacon IE ownership A hidden-group probe-response enCVE-2026-98823 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: preserve hidden-group beacon IE ownership A hidden-group probe-response entry borrows its beacon IEs from the group's beacon entry. cfg80211_update_assoc_bss_entry() can pass such an entry to cfg80211_update_known_bss() when merging scan entries after a channel switch. Copying the borrowed beacon_ies into the associated entry gives the same allocation two owners. Releasing the group's beacon entry can then leave the associated entry pointing to freed IEs, which are freed again when that entry is released. Skip beacon IE replacement when the source entry belongs to a hidden group. Preserve probe-response processing, the subsequent metadata updates, and the existing rejection path for conflicting hidden beacon updates.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: prevent AP VLAN tx from other interfaces Since the station lookup was factCVE-2026-98822 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: prevent AP VLAN tx from other interfaces Since the station lookup was factored out of ieee80211_build_hdr(), ieee80211_lookup_ra_sta() uses sta_info_get_bss() for all AP and AP VLAN frames, not only for control port frames. A unicast frame sent on one interface thus matches a station of a different VLAN of the same BSS and is transmitted to it. Only match stations of the interface the frame is sent on, except for control port frames, since those may be sent for VLAN stations directly on the BSS interface.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: block: reject polled dio with user integrity metadata IOCB_HAS_METADATA leaves iocb->privaCVE-2026-98821 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: block: reject polled dio with user integrity metadata IOCB_HAS_METADATA leaves iocb->private as a uio_meta, while iocb_bio_iopoll() expects a bio. Since 2729a60bbfb9, metadata I/O always uses __blkdev_direct_IO(), which never publishes the bio for polling, so IOPOLL calls bio_poll() on the uio_meta. Reproducer: io_uring IOPOLL plus a PI attribute on an integrity device (scsi_debug dif=1 dix=1). KASAN reports: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000004 KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027] RIP: 0010:bio_poll+0x9d/0x4b0 Call Trace: iocb_bio_iopoll+0x5b/0x80 io_uring_classic_poll+0xf3/0x140 io_do_iopoll+0x4e3/0xc00 io_iopoll_check+0x275/0x560 __do_sys_io_uring_enter+0x2e5/0x720 Return -EOPNOTSUPP when HIPRI is combined with user metadata.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: blk-mq: set RQF_USE_SCHED when the operation is known The cached requests are allocated foCVE-2026-98820 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: blk-mq: set RQF_USE_SCHED when the operation is known The cached requests are allocated for one operation but can be handed out for another. A passthrough command has RQF_USE_SCHED cleared, so using those flags for a subsequent read/write bio will insert it into the scheduler without ->prepare_request() and frees it without ->finish_request(). For kyber, this leaks the domain token acquired at dispatch and stalls the queue. Don't set RQF_USE_SCHED based on the first operation the batch happened to be allocated for. Instead, set it after the request is claimed by an operation. Introduce a helper function, blk_mq_rq_late_init() for this, and absorb blk_mq_rq_time_init() since the two run together.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: validate DDC record lengths Parse DDC record lengths in unsigned storaCVE-2026-98819 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel: validate DDC record lengths Parse DDC record lengths in unsigned storage so 0xFF does not wrap. Reject records smaller than the mandatory three-byte header, records exceeding U8_MAX, and records exceeding remaining firmware bytes before issuing Intel_Write_DDC. This issue was reported by Claude Mythos.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: mm/slab: do not wake up kswapd in __kfree_rcu_sheaf() Since kfree_rcu() can be called undeCVE-2026-98818 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: mm/slab: do not wake up kswapd in __kfree_rcu_sheaf() Since kfree_rcu() can be called under pi_lock (a raw spinlock in the scheduler), kfree_rcu() itself should never allocate memory with __GFP_KSWAPD_RECLAIM as waking up kswapd ends up acquiring pi_lock, which leads to a deadlock. Reproducing the issue even intentionally was not straightforward. The set_cpus_allowed_force() path that is called under pi_lock is exercised very rarely, and competing tasks that allocate memory will most likely wake kswapd up. Therefore the existence of the deadlock was verified with a modified kernel that has a lockdep map for waking up kswapd: ====================================================== WARNING: possible circular locking dependency detected 7.2.0-rc1-slab-for-next+ #10 Not tainted ------------------------------------------------------ git/6660 is trying to acquire lock: ffff8e524533c550 (&p->pi_lock){-.-.}-{2:2}, at: _raw_spin_lock_irqsave+0x12/0x20 but task is already holding lock: ffff8e57bffff1a0 (&pgdat->kswapd_wait){....}-{3:3}, at: _raw_spin_lock_irqsave+0x12/0x20 which lock already depends o
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: ASoC: SDCA: Add better pm_runtime error handling in func probe Add a common error path in CVE-2026-98817 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ASoC: SDCA: Add better pm_runtime error handling in func probe Add a common error path in probe that balances the runtime PM reference.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overflow of jump offset in constant blinding bpf_jit_blind_insn() rewrites 'if rXCVE-2026-98816 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix overflow of jump offset in constant blinding bpf_jit_blind_insn() rewrites 'if rX op imm goto off' into: AX = imm ^ rnd AX ^= rnd if rX op AX goto off and subtracts 2 from off when the jump is backward. off is s16, so -32767 and -32768 wrap and the jump goes 32767 insns forward, past the end of the prog. The jump is inside the patch, hence bpf_adj_branches() doesn't check it. The kernel crashes when such prog runs with bpf_jit_harden=2. Return -ERANGE in such case. bpf_jit_blind_constants() fails the same way when blinding of other insns moves a jump out of range.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: nvme: fix cdev lifetime Sashiko bot reported a potential problem for the cdev lifetime in CVE-2026-98815 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: nvme: fix cdev lifetime Sashiko bot reported a potential problem for the cdev lifetime in [0] - the code there is heavily based on the NVMe code. Currently the NS head .open and .release file_operations methods take and put a reference to the nvme_ns_head to ensure that this structure does not disappear while we open fds for that cdev. In multipath mode, when we teardown the NS head, we call nvme_cdev_del() -> cdev_device_del() -> cdev_del(). However after cdev_del() returns, cdevs already open will remain and their fops will still be callable. As such, we can still reference the cdev after the nvme_ns_head reference count drops to 0 (and is freed). This can be shown with an application which delays between opening the cdev and issuing the ioctl while the NS head is being torn down: # ./ioctl_file /dev/ng1n1 & # waiting 10 seconds .... # ./ini_nvme_teardown.sh [ 21.221718] nvme nvme1: Removing ctrl: NQN "nvme-test-target" [ 21.274609] nvme nvme2: Removing ctrl: NQN "nvme-test-target" # now going to issue ioctl .... [ 26.549285] ================================================================== [ 26.5
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: nvme: fix command effects log lifetime for multipath heads KASAN reported a use-after-freeCVE-2026-98814 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: nvme: fix command effects log lifetime for multipath heads KASAN reported a use-after-free when an I/O passthrough command was sent through a multipath namespace head after the controller path that first created the head had been removed: BUG: KASAN: slab-use-after-free in nvme_command_effects+0x192/0x200 [nvme_core] Read of size 4 at addr ffff888141b14400 by task nvme/19811 nvme_command_effects+0x192/0x200 [nvme_core] nvme_cmd_allowed+0x7e/0x1b0 [nvme_core] nvme_user_cmd.constprop.0+0x1b5/0x450 [nvme_core] nvme_ns_head_chr_ioctl+0xf4/0x2a0 [nvme_core] Move the log cache to the subsystem, with one entry per command set. Both controllers and namespace heads hold subsystem references, keeping their log pointers valid until subsystem release.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Hold map BTF for the memory allocator destructor record bpf_ma_set_dtor() duplicates CVE-2026-98813 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bpf: Hold map BTF for the memory allocator destructor record bpf_ma_set_dtor() duplicates map->record so that the bpf_mem_alloc destructor can release the special fields of hash and rhash map elements once the allocator frees them for good. btf_record_dup() only acquires references on kernel and module BTF. Fields whose types live in the map BTF keep pointing into it: a kptr to a local type refers to map->btf, and a list_head or rb_root field carries a value_rec owned by the struct meta table of map->btf. That borrowed state can outlive the map. When RCU callbacks are still in flight, bpf_mem_alloc_destroy() copies the allocator and defers the final drain, together with the destructor context, to a workqueue. bpf_map_free() then frees map->record and drops the map's BTF reference as soon as map_free() returns. Once the program that loaded the BTF is gone as well, the BTF is freed while the worker still uses the duplicate. The worker dereferences it through btf_is_kernel() and btf_find_struct_meta() in bpf_obj_free_fields() when destroying elements that were freed under RCU, and through btf_is_kernel() in btf_rec
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net/mctp: publish the mctp_dev only after it is initialised mctp_add_dev() links the new mCVE-2026-98812 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net/mctp: publish the mctp_dev only after it is initialised mctp_add_dev() links the new mctp_dev into dev->mctp_ptr before mdev->dev is assigned, so a reader that picks the device up in that window dereferences a net_device pointer that is still NULL: KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7] Call Trace: <TASK> ? __pfx_mctp_sendmsg (./include/linux/sockptr.h:49) ? __pfx_mctp_dst_output (net/mctp/route.c:41) ? selinux_socket_sendmsg (security/selinux/hooks.c:5278) ____sys_sendmsg (net/socket.c:775 (discriminator 1) net/socket.c:790 (discriminator 1) net/socket.c:2684 (discriminator 1)) ? __pfx_____sys_sendmsg (net/socket.c:1131) ? __pfx_copy_msghdr_from_user (net/socket.c:2590) ? update_cfs_rq_load_avg (kernel/sched/fair.c:5478) ___sys_sendmsg (net/socket.c:2738) ? __pfx____sys_sendmsg (net/socket.c:2625) ? perf_event_task_tick (./include/linux/rcupdate.h:838) ? sched_tick (kernel/sched/core.c:5818) ? clockevents_program_event (kernel/time/clockevents.c:372) ? fdget (./include/linux/rcupdate.h:873 fs/file.c:1100) __sys_sendmsg (net/socket.c:2770) ? __pfx___sys_sendms
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: reclaim an empty proto on the error path Two racing tc filter add requCVE-2026-98811 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_api: reclaim an empty proto on the error path Two racing tc filter add requests on the same chain/prio of an unlocked classifier both run change() on the shared proto and both can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up because the loser's handle is still in the idr, and the loser's error path drops only its own reference without a second reclamation attempt. The empty proto stays linked in the chain, holding the chain reference, a block reference and the classifier module reference until the chain or block is torn down. Reclaim the proto on the error path of any failed request that holds a proto reference. The reclamation is emptiness-gated: tcf_chain_tp_delete_empty() unlinks the proto only when delete_empty() admits it is empty, so a live shared proto is never unlinked. A proto the request created is reclaimed unconditionally - it is the only owner, so marking it for deletion is safe even without a delete_empty callback. Classifiers without one (the check marks the proto unconditionally) are rtnl-serialized, so the raced window this guard closes cannot arise for them. T
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue() ieee80211_CVE-2026-98810 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue() ieee80211_monitor_select_queue() validates the skb length using skb->len before dereferencing pointers into skb->data to access the 802.11 header. However, skb->len includes data in both the linear head buffer and non-linear fragments/pages. When AF_PACKET sends a packet large enough to become non-linear, the 802.11 header at skb->data + len_rthdr may extend past the linear head buffer even though skb->len appears sufficient. This leads to a slab-out-of-bounds read when accessing hdr->frame_control, as the kernel reads beyond the allocated skb head buffer: BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220 syzbot has hit the same issues. Fix this by checking skb_headlen(skb) (which gives the length of the linear data region) instead of skb->len before dereferencing skb->data pointers. This ensures the required bytes are actually present in the linear portion of the skb. Apply the same fix to ieee80211_validate_radiotap_len() which has the same class of bug: it uses skb->len to validate accesses to skb-
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister hci_unregister_dev() disabCVE-2026-98809 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister hci_unregister_dev() disables cmd_work and cmd_timer, then calls hci_cmd_sync_clear(), whose cancel_work_sync() waits for hci_cmd_sync_work() to return. That worker dequeues and runs every entry on cmd_sync_work_list. With cmd_work disabled nothing reaches the controller, so each queued HCI command waits the full HCI_CMD_TIMEOUT (2s). The backlog has no bound. Userspace can keep queuing MGMT commands such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't answer. Closing /dev/vhci then blocks in vhci_release() for backlog * 2s: INFO: task syz-executor:5749 blocked for more than 143 seconds. cancel_work_sync hci_cmd_sync_clear hci_unregister_dev vhci_release In a local reproduction the backlog held more than 5000 entries, which comes to hours of hang. Stop the worker from taking new entries once HCI_UNREGISTER is set, and wake any request still waiting with -ENODEV before cancelling the work. The entries left over are destroyed with -ECANCELED by the existing sweep in hci_cmd_sync_clear(). They stay on the list until the wor
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: systemport: Fix buffer overflow in bcm_sysport_get_stats() When running on SYSTEMPORTCVE-2026-98808 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: systemport: Fix buffer overflow in bcm_sysport_get_stats() When running on SYSTEMPORT Lite, certain statistics are unsupported and skipped during bcm_sysport_get_stats(). The variable 'j' tracks the compacted index into the destination data buffer, whereas 'i' iterates over all elements in bcm_sysport_gstrings_stats. Because the buffer allocated by ethtool is sized only according to bcm_sysport_get_sset_count(), storing values at data[i] instead of data[j] writes past the allocated array bounds, leading to memory corruption. Fix this by writing to data[j] instead of data[i].
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds when handling team device events The mlx5_handle_changeupCVE-2026-98807 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix slab-out-of-bounds when handling team device events The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on team_port structures causes KASAN to detect an out-of-bounds memory access since team_port is smaller than bond slave. Fix this by wrapping the bond-specific API calls with a check for bonding devices. This allows the function to still process LAG events for both bonding and teams but only calls bond-specific functions when dealing with actual bonding devices. For mlx5_handle_changeinfodata_event(), keep the explicit bond check as mlx5 doesn't handle state information for team ports anyway. Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6: - Bonding: PASS (no regressions) - Team device: PASS (no KASAN errors)
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled Previously, BPID assignmCVE-2026-98806 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix aura BPID assignment when CONFIG_DCB is enabled Previously, BPID assignment under CONFIG_DCB assumed `queue_to_pfc_map` was always initialized. For SDP VFs this leads to invalid memory access as it was not initialized. This patch adds a NULL check for `queue_to_pfc_map` before dereferencing it. Also, simplifies the logic by always assigning a default BPID first, then conditionally overriding it if CONFIG_DCB is enabled and the map exists.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: tipc: prevent GCM nonce reuse on peer key changes TIPC can encrypt traffic between nodes uCVE-2026-98805 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: tipc: prevent GCM nonce reuse on peer key changes TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce. Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports can
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: page_pool: fix use-after-free in page_pool_recycle_ring_bulk() With CONFIG_PAGE_POOL_CVE-2026-98804 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: page_pool: fix use-after-free in page_pool_recycle_ring_bulk() With CONFIG_PAGE_POOL_STATS=y, page_pool_recycle_ring_bulk() updates the recycle stats after dropping the producer lock. If it just recycled the last inflight netmems of a pool being destroyed, page_pool_release() can pass its producer-lock barrier and free the pool before recycle_stat_add() runs. Commit fcc680a647ba7 ("page_pool: allow mixing PPs within one bulk") moved this stat update after the unlock. Commit 271683bb2cf32 ("page_pool: Fix use-after-free in page_pool_recycle_in_ring") later added the barrier, but only fixed page_pool_recycle_in_ring(). Move the update back under the lock.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix rx Scatter-Gather support When a received frame is larger than dma_buf_szCVE-2026-98803 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: fix rx Scatter-Gather support When a received frame is larger than dma_buf_sz, the DMA scatters it across multiple RX descriptors (rx Scatter-Gather). The secondary RX buffer (sec_page) was only allocated and programmed when split-header (SPH) was active, so for regular frames buffer2 was neither allocated nor backed by a valid mapping. As soon as an incoming frame overflowed buffer1, the DMA wrote the overflow into the unmapped secondary-buffer address, triggering an SMMU translation fault on IOMMU-based platforms: arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11 arm-smmu 15000000.iommu: FSR = 00000402 [Format=2 TF], SID=0x1c90 arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1] Enable scatter-gather for non-SPH frames on cores that can program an independent secondary RX buffer (GMAC4/XGMAC): allocate and mark buffer2 as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account for it in the buffer length computation. Legacy cores have no set_sec_addr op, so they keep buffer2 disabled. Since buffe
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: seg6: ensure packet data is writable before modifying SRH and IPv6 DA advance_nextseg() moCVE-2026-98802 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: seg6: ensure packet data is writable before modifying SRH and IPv6 DA advance_nextseg() modifies the SRH Segments Left field and the IPv6 destination address without ensuring the packet data is writable. seg6_next_csid_advance_arg() has the same problem when it advances the NEXT-C-SID argument in the destination address. The skb may be cloned, for example by an AF_PACKET socket receiving on the ingress device. advance_nextseg() and seg6_next_csid_advance_arg() then write into the packet data shared with the clone. A read from that socket can return the modified packet instead of the received one. The simplified path below shows this for advance_nextseg(): __netif_receive_skb_one_core __netif_receive_skb_core deliver_skb [orig: users=2, cloned=0] packet_rcv skb_clone clone queued to the AF_PACKET socket consume_skb(orig) [orig: users=1, cloned=1] ipv6_rcv ip6_rcv_core skb_share_check: no-op [orig: users=1] [...] input_action_end_core advance_nextseg writes into the data shared with the clone Call skb_ensure_writ
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: restrict SO_RESERVE_MEM to TCP sockets and cap max value Commit 2bb2f5fb21b0 ("net: aCVE-2026-98801 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: restrict SO_RESERVE_MEM to TCP sockets and cap max value Commit 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") and commit d00c8ee31729 ("net: fix possible NULL deref in sock_reserve_memory") only checked sk_has_account(sk), which is true for both TCP and UDP sockets. However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP: - On UDP sockets, sk->sk_forward_alloc is protected by sk->sk_receive_queue.lock, whereas sock_reserve_memory() and sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt sk_forward_alloc and memcg accounting. - udp_rmem_release() reclaims excess sk_forward_alloc without accounting for sk_unused_reserved_mem(sk). Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed. In addition, reject val > SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an uppe
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Wait for an RCU tasks grace period before freeing trampoline progs When a prog is detCVE-2026-98800 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bpf: Wait for an RCU tasks grace period before freeing trampoline progs When a prog is detached from a trampoline, it is freed after an RCU grace period, or an RCU tasks trace one if it is sleepable. This covers the tasks that are running the prog, since the prog's enter helper takes the matching read lock before the prog is called. On a preemptible kernel, it doesn't cover a task that was preempted in the trampoline just before the enter helper. That task holds no lock yet, and it calls the prog after it was freed: BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_enter_recur+0x3a5/0x3f0 Read of size 8 at addr ffffc90000055040 by task candidate/110 CPU: 1 UID: 0 PID: 110 Comm: candidate Not tainted 7.3.0-rc2-00014-g15071f2a1263-dirty #2 PREEMPT(full) Call Trace: <TASK> __bpf_prog_enter_recur+0x3a5/0x3f0 bpf_trampoline_6442509193+0x37/0xf1 __x64_sys_futex+0x9/0x410 do_syscall_64+0xb0/0x530 ... Wait for an RCU tasks grace period before the existing one when freeing a prog that was linked to a trampoline. An RCU tasks grace period only ends once the tasks that were preempted have run again
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Skip detached progs in trampoline images that are still in use bpf_tramp_image_put() CVE-2026-98799 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bpf: Skip detached progs in trampoline images that are still in use bpf_tramp_image_put() makes sure a trampoline image is not freed while a task may still be running in it, but nothing similar is done for the progs called by that image. Detach drops the last prog reference right away and the prog is freed after grace periods, on the basis that a task still in the traced function skips the fexit progs once the nop at ip_after_call is patched to a jump. That leaves out a task sleeping in a sleepable prog that runs before the detached one, which no grace period waits for: CPU 0 CPU 1 in image I, sleeping in prog S detach P from I's trampoline -> new image, bpf_tramp_image_put(I) bpf_prog_put(P), last ref grace periods, P freed back from S __bpf_prog_enter(P) call P->bpf_func If S and P are fexit progs the task is already past the patched jump, and fentry only images don't have one. On x86 this is an int3 in poisoned bpf_pr
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix NULL dereference in set_coalesce before first open The Rx ring priv andCVE-2026-98798 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: bcmgenet: fix NULL dereference in set_coalesce before first open The Rx ring priv and index are only set in bcmgenet_init_rx_ring(), which runs at open. Setting the Rx coalescing parameters on an interface that was never opened, e.g. "ethtool -C eth0 rx-usecs 50", dereferences a NULL ring->priv. The oops happens with RTNL held, so networking stays stuck until a reboot: Unable to handle kernel paging request at virtual address 0000000000002788 pc : bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 lr : bcmgenet_set_coalesce+0xe8/0x180 Call trace: bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 (P) __ethnl_set_coalesce.isra.0+0x490/0x570 ethnl_set_coalesce+0x48/0xc0 ethnl_default_set_doit+0xf4/0x230 genl_family_rcv_msg_doit+0xe8/0x160 genl_rcv_msg+0x220/0x2a0 netlink_rcv_skb+0x68/0x140 genl_rcv+0x40/0x60 netlink_unicast+0x338/0x3c0 netlink_sendmsg+0x19c/0x3f8 __sock_sendmsg+0x64/0xc0 __sys_sendto+0x124/0x198 __arm64_sys_sendto+0x30/0x48 Set priv and index at probe. Writing the registers while the interface is down is harmless because open resets the MAC and bcmgenet_init_rx_c
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: cap skb->queue_mapping when the tx queue is picked skbedit can set skb->queue_mappingCVE-2026-98797 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: cap skb->queue_mapping when the tx queue is picked skbedit can set skb->queue_mapping and raise the per-CPU skip_txqueue flag so __dev_queue_xmit() honours the mapping. __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterwards, so the flag was not confined to the xmit that set it: a nested xmit (mirred redirect or mirror, or a drop after skbedit) could set the flag and the outer xmit would consume it for an skb that never went through skbedit. A forwarded packet still carries the ingress NIC's rx_queue + 1 in skb->queue_mapping, so the outer device then indexes its tx queue state with that stale value. Taprio's child array q->qdiscs[] is sized to the device's queue count, so taprio_enqueue() indexes past its allocation and dereferences the result as a struct Qdisc *. We (ab)use the skb->nf_skip_egress which means "skip netfilter egress for this packet" to tag to "am I in tc egress?". Despite the overload I dont see it as a conflict since the marker is set only around the single sch_handle_egress() call and ingress path is guarded by tc_at_ingress. I will send a followup(net
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: allocate dummy netdev sooner The RX rings and the shared NAPI CVE-2026-98796 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: ethernet: mtk_eth_soc: allocate dummy netdev sooner The RX rings and the shared NAPI are carried by an internal "dummy" netdev (eth->dummy_dev). mtk_probe() creates that dummy device, and adds the shared tx/rx NAPI to it, only after the MAC netdevs have been registered. That order has been there since the MT7623 support was added and leaves a window in which the netdevs are visible to the network core before the shared NAPI and the dummy device exist. If anything brings the first netdev up during that window (e.g. netifd opening the WAN link the instant the interface is registered), the first-open path runs without them. On NETSYS v2 and later SoCs mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev == NULL: WARNING: CPU: ... Missing net_device from driver in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs (MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open instead calls napi_enable() on a napi_struct that netif_napi_add() has not initialised yet and dereferences a NULL napi->dev. Allocate the dummy netdev and add the shared tx/rx NAPI to it bef
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net: sparx5: skip ptp deinit if init was skipped sparx5_ptp_init() returns early on the baCVE-2026-98795 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net: sparx5: skip ptp deinit if init was skipped sparx5_ptp_init() returns early on the base lan969x variants because they do not have the SPX5_FEATURE_PTP flag. It also returns early when no "ptp" interrupt is described. Unbinding the driver then causes a NULL pointer dereference when cleaning up uninitialized tx_skbs queues: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: skb_queue_purge_reason+0x68/0x120 (P) sparx5_ptp_deinit+0x64/0xc0 mchp_sparx5_remove+0x38/0x70 platform_remove+0x20/0x30 device_remove+0x4c/0x80 Before per-port tx_skbs were added, a NULL dereference would have happened when calling ptp_clock_unregister() on the never-registered PTP clocks. Fix by returning early in sparx5_ptp_deinit() if PTP is not used.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: ipvs: filter some flags received in the backup server While the IPVS SYNC protocol is not CVE-2026-98794 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: ipvs: filter some flags received in the backup server While the IPVS SYNC protocol is not secure by design we can still protect the backup server from messages that can wreak havoc. This commit addresses problems from received connection flags or their combinations. We now drop messages as follows: 1. the NO_CPORT+TEMPLATE combination allows lookups for normal connections to hit template which can break in many ways. While the master does not sync connections with NO_CPORT flag, i.e. before they are established, we still accept NO_CPORT without TEMPLATE. 2. ONE_PACKET: it is not sent by master, so we do not expect it in backup. Before now it was ignored by IP_VS_CONN_F_BACKUP_MASK for protocol v1 while protocol v0 created connections that are not hashed and dropped immediately. Better to apply the IP_VS_CONN_F_BACKUP_MASK also to the flags from v0 messages for consistency with v1.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: netfilter: bpf: reject invalid NAT manipulation types As bpf_ct_set_nat_info() is not valiCVE-2026-98793 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: netfilter: bpf: reject invalid NAT manipulation types As bpf_ct_set_nat_info() is not validating the NAT manipulation type a wrong value can be passed directly to nf_nat_setup_info(). This triggers the WARN_ON() at nf_nat_setup_info() and if panic_on_warn isn't set, then IPS_SRC_NAT_DONE is set without adding nat_bysource and conntrack cleanup tries to unlink an uninitialized hlist node. Fix this by checking that NAT manipulation type is correct before calling nf_nat_setup_info(). In addition, if the WARN_ON is hit, return NF_DROP instead of continuing with the processing to avoid similar situations in the future.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: generalize pending status bit Rename NF_FLOW_HW_PENDING to NF_FLOW_PCVE-2026-98792 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: generalize pending status bit Rename NF_FLOW_HW_PENDING to NF_FLOW_PENDING and use it to inhibit the flowtable GC worker until pending hw offload work has been completed. Apparently, nf_flow_offload_stats() can schedule work to retrieve stats while the flow is being removed by GC. And this bit can also be used in a follow up patch to disable GC until the flow has been fully added in both directions. Revert the reordering done in commit d644b23afe1e ("netfilter: flowtable: publish HW_DEAD after worker is done") to prevent a race between GC and hw offload handler.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference During XSK TX queue teardown,CVE-2026-98791 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix AF_XDP TX timestamp teardown NULL dereference During XSK TX queue teardown, outstanding descriptors are completed without a CQE. If one requested a TX timestamp, the completion path passes that NULL CQE to mlx5e_xsk_fill_timestamp(), which dereferences it. Return zero when no CQE is available, indicating that teardown did not produce a TX timestamp.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: perf: Fix race between perf_event_exit_task() and perf_pending_task() A race condition exiCVE-2026-98790 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: perf: Fix race between perf_event_exit_task() and perf_pending_task() A race condition exists between perf_event_exit_task() and perf_pending_task() during begin_new_exec(). During begin_new_exec(), perf_event_exit_task() may be called, and the PF_EXITING flag is not set on task. So perf_sigtrap() continues to execute and triggers WARN_ON_ONCE(event->ctx->task != current). Since both task exit and exec paths can call perf_event_exit_task() which sets ctx->task to TASK_TOMBSTONE, fix this by explicitly checking if event->ctx->task equals TASK_TOMBSTONE and dropping the redundant PF_EXITING check.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Fix objects stuck in free_by_rcu_ttrace do_call_rcu_ttrace() returns early when call_CVE-2026-98789 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix objects stuck in free_by_rcu_ttrace do_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set and leaves the objects in free_by_rcu_ttrace. __free_rcu() frees waiting_for_gp_ttrace only and clears the flag. Hence the objects that free_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight stay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for the same bpf_mem_cache again, which may never happen. The number of such objects is not bounded. Turn call_rcu_ttrace_in_progress into three states: 0 - idle 1 - __free_rcu() is queued 2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since do_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check free_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache without waiting for RCU callbacks when the flag is zero. Now __free_rcu() queues itself, so the one that didn't see 'draining' may do call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in free_mem_alloc(). Queue it under rcu_read_lock() and
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: futex: Fix private hash use-after-free on resize poll_state_synchronize_rcu(mm->futex.phasCVE-2026-98788 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: futex: Fix private hash use-after-free on resize poll_state_synchronize_rcu(mm->futex.phash.batches) is used by futex_ref_drop() to check that a grace period has passed since the current hash was published. This relies on batches referencing a grace period which started after the hash pointer was assigned. __futex_pivot_hash() sets mmph->batches before it replaces mmph->hash: scoped_guard(rcu) { mmph->batches = get_state_synchronize_rcu(); rcu_assign_pointer(mmph->hash, new); } The scoped_guard(rcu) doesn't stop new grace periods from starting, and if one starts between those two assignments, futex_ref_drop() can move forward while a reader still holds a pointer to the old hash. Fix things by setting mmph->batches after assigning mmph->hash. The scoped_guard(rcu) isn't needed, so let's drop that as well.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: bpf: Fix missing migration protection in __rhtab_map_lookup_and_delete_batch() bpf_mem_cacCVE-2026-98787 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix missing migration protection in __rhtab_map_lookup_and_delete_batch() bpf_mem_cache_free_rcu() uses this_cpu_ptr() which requires migration to be disabled. All callers of rhtab_delete_elem() disable migration except __rhtab_map_lookup_and_delete_batch(), which calls it under rcu_read_lock() only. On CONFIG_PREEMPT_RCU, rcu_read_lock() does not disable preemption or migration, so the task can migrate between CPUs during the delete loop, causing this_cpu_ptr() to trigger: BUG: using smp_processor_id() in preemptible [00000000] code Fix by wrapping the delete loop in migrate_disable()/migrate_enable() in __rhtab_map_lookup_and_delete_batch(), matching the migration protection that the other callers already provide.
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: guard dc_sink dereferences in MST mode validation dm_dp_mst_is_port_suppoCVE-2026-98786 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: guard dc_sink dereferences in MST mode validation dm_dp_mst_is_port_support_mode() reads aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check, and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL check. dc_sink is cleared asynchronously on MST unplug, and both functions run from paths that the driver's own comments document as racing that teardown: the connector probe worker's ->mode_valid callback and a compositor's atomic check, neither of which holds the MST manager lock that the teardown path uses. The former does have an existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in every path that clears dc_sink, so it doesn't cover this. Fail the port-support check and skip the FRL conversion path when the sink is already gone. (cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7)
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org
Oct 18, 2026In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend dc_state_create_copy(CVE-2026-98785 · Computers, phones & browsers · Linux · reported by 416baaa9-dc9f-4396-8d5f-8c081fb06d67
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend dc_state_create_copy() can return NULL on allocation failure. dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts() and continues execution, returning success. dm_resume() then dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the following dc_state->stream_count loop, crashing during GPU reset recovery. Return -ENOMEM immediately if the copy fails, so the caller aborts suspend instead of leaving a NULL cached state for resume. (cherry picked from commit 84b6d7932fdd2857795a257f9f258562a3cddcab)
Product
Linux
What to do
Apply the vendor’s update. The NVD record links to the advisory.
Full record and what to do →NVD record git.kernel.org git.kernel.org

Where this comes from: the exploited list is CISA’s Known Exploited Vulnerabilities catalog. Everything else is the whole National Vulnerability Database, where each record is published by the team that found the bug (Wordfence, Patchstack, WPScan, the vendors themselves and others); we show who. Exploit odds are FIRST’s EPSS, updated daily. Titles and categories are ours, so check the linked record before acting on a detail. For a write-up of the big ones, see our advisories. Every vendor, and every WordPress plugin and theme with a recorded flaw, also has its own page. All of it is free to reuse as JSON, CSV or RSS.

Weekly security brief

The flaws that hit local websites, every Friday.

One short email: what got exploited this week, which WordPress plugins broke, and what to check. Unsubscribe in one click.

Vulnerability database

The flaws that hit local websites, every Friday.

Tell us what you're building.