Total
398400 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2026-74747 | 2026-08-27 | N/A | 7.8 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: ipvs: revalidate ihl to prevent out-of-bounds access While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent out-of-bounds access. One such place reported by Sashiko is ip_vs_nat_icmp() where local process can change the ihl field and after skb_ensure_writable() we can see larger value which is a problem for the ip_send_check(cih) calls. Add check to drop the packet if the ihl field is changed. | |||||
| CVE-2026-74746 | 2026-08-27 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: publish GC-visible tuple last nf_flow_table_iterate() only treats original-direction tuple nodes as owning entries. Publishing the original node first lets GC observe and free a flow while flow_offload_add() is still inserting the reply node. Publish the reply node first and the original node last so GC never sees a partially installed flow. KASAN can trigger slab-use-after-free read and write reports in the flowtable/rhashtable path (rht_deferred_worker, jhash, flow_offload_del, flow_offload_lookup, etc.). | |||||
| CVE-2026-74745 | 2026-08-27 | N/A | 7.5 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: eth: bnxt: avoid deadlock when canceling IRQ affinity notifier Unregistering IRQ affinity notifiers waits for the callback synchronously. bnxt takes the netdev instance lock in the notifier (to restart the queue) and cancels the work under the same lock. This may obviously deadlock. Move the restart to the async service task. The queue restart isn't super time sensitive. Store the new TPH tag, schedule the task. Safely canceling the service task is already ironed out. In bnxt_request_irq() the order of registering notifier, affinity and initial TPH programming has to be inverted. I think it was racy previously since user may trigger an update as soon as notifier is installed. There's a small known gap - if pcie_tph_get_cpu_st() fails at init and the target tag is 0 we may miss programming the entry. This does not seem worth fixing, the code has skip-on-failure all over the place, anyway. | |||||
| CVE-2026-74744 | 2026-08-27 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: ipvlan: inherit needed_headroom and needed_tailroom from phy_dev ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying phy_dev (or stacked lower device) requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. | |||||
| CVE-2026-74743 | 2026-08-27 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: macvlan: inherit needed_headroom and needed_tailroom from lowerdev macvlan devices inherit hard_header_len from lowerdev during macvlan_init(), but leave needed_headroom and needed_tailroom set to 0. When the underlying lowerdev requires extra headroom or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx headroom), upper layers calculating packet headroom and tailroom fail to reserve sufficient space. This can result in reallocation overhead, skb headroom underflows, or KASAN slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header() prepends header data or when lower devices append tailroom. Fix this by: 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init(). 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events. | |||||
| CVE-2026-74742 | 2026-08-27 | N/A | 7.5 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: veth: fix queue index used to wake the peer txq in veth_poll veth_poll() derives the index of the peer TX queue to wake from rq->xdp_rxq.queue_index. That field is only initialized by xdp_rxq_info_reg() in veth_enable_xdp_range(), which runs only when an XDP program is attached. On the plain GRO/NAPI path (veth_napi_enable_range()) xdp_rxq_info_reg() is never called, so queue_index stays 0 for every queue, as priv->rq is zero-allocated. So in a multi-queue setup with GRO enabled and no XDP program attached, every NAPI instance looks at the peer's TX queue 0. If veth_xmit() stops peer TX queue 1 because the ptr_ring is full (NETDEV_TX_BUSY), nothing ever wakes it again: the poller draining queue 1 wakes queue 0 instead. veth implements no ndo_tx_timeout, so the netdev watchdog does not kick in either, and the queue stays stopped indefinitely. Derive the index from the position of the rq within priv->rq instead, which is correct regardless of whether XDP was ever enabled. Scripts to reproduce the stall are available at https://github.com/netoptimizer/veth-backpressure-performance-testing | |||||
| CVE-2026-74741 | 2026-08-27 | N/A | 7.5 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: net: ngbe: fix NULL pointer dereference in non-MSI-X interrupt enabling In non-MSI-X mode (such as legacy INTx or single MSI), wx->msix_entry is not allocated or initialized. Calling NGBE_INTR_MISC(wx) dereferences wx->msix_entry->entry, leading to a NULL pointer dereference crash. This issue was introduced by fixing the IRQ vector when the number of VFs is 7. Fix the issue by explicitly checking `pdev->msix_enabled` to determine the correct vector index. Additionally, as a side fix, set the interrupt mask to BIT(0) for the non-MSI-X fallback. In MSI/INTx mode, the MISC and queue interrupts share vector 0, and the WX_PX_MISC_IVAR register is only valid in the MSI-X case. Thus, BIT(0) is the correct mask for the miscellaneous cause when MSI-X is disabled. | |||||
| CVE-2026-74739 | 2026-08-27 | N/A | 7.8 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_u32: skip hash tables in u32_bind_class() u32_walk() enumerates both struct tc_u_hnode and struct tc_u_knode through the walker callback. u32_bind_class() unconditionally casts the passed fh to tc_u_knode and accesses &n->res, so when fh is actually a tc_u_hnode, which has no tcf_result member, this results in a slab-out-of-bounds read of res->classid in tc_cls_bind_class(). The issue can be reproduced with the following commands: tc qdisc add dev lo root handle 1: hfsc tc class add dev lo parent 1: classid 1:1 hfsc sc rate 1000kbit tc filter add dev lo parent 1:1 protocol ip prio 1 u32 match u32 0 0 flowid 1:1 tc class add dev lo parent 1: classid 1:2 hfsc sc rate 2000kbit Fix this by skipping hash tables via the TC_U32_KEY(handle) check. | |||||
| CVE-2026-74737 | 2026-08-27 | N/A | 9.8 CRITICAL | ||
| In the Linux kernel, the following vulnerability has been resolved: net: ethernet: ti: am65-cpsw-nuss: Fix port_id extraction from SRC TAG On the packet reception path, the ID of the MAC Port on which the packet was received, is embedded in the RX DMA Descriptor's metadata. The ID is extracted using the helper function cppi5_desc_get_tags_ids() which fills in the 16-bit Source Tag into the 'port_id' variable. However, it is only the lower 8-bits of the 16-bit Source Tag that represent the MAC Port ID, while the upper 8-bits are Hardware-Reserved and carry an arbitrary value. With the existing logic, sporadic kernel crash is observed due to the subsequent driver code accessing out-of-bound memory because of an invalid port_id. Hence, fix the port_id extraction logic to use only the lower 8-bits of the Source Tag as the MAC Port ID. | |||||
| CVE-2026-74736 | 2026-08-27 | N/A | 7.8 HIGH | ||
| In the Linux kernel, the following vulnerability has been resolved: net/sched: cls_bpf: reject dev-bound programs bound to a different device cls_bpf_prog_from_efd() obtained a SCHED_CLS program via bpf_prog_get_type_dev() but never verified that a device-bound (offloaded) program's bound netdev matches the TC netdev the classifier is being attached to. This let a program loaded with prog_ifindex for device A be attached via cls_bpf + skip_sw to device B; deleting device A then destroyed the program's offload state while it was still attached to device B, triggering a netdevsim WARN (panic with panic_on_warn=1). Mirror the XDP attach path (net/core/dev.c) and reject the attach with -EINVAL when a dev-bound program's bound device does not match the target device. | |||||
| CVE-2025-3511 | 2026-08-27 | N/A | 7.5 HIGH | ||
| Improper Validation of Specified Quantity in Input vulnerability in Mitsubishi Electric Corporation CC-Link IE TSN Remote I/O module, CC-Link IE TSN Analog-Digital Converter module, CC-Link IE TSN Digital-Analog Converter module, CC-Link IE TSN FPGA module, CC-Link IE TSN Remote Station Communication LSI CP620 with GbE-PHY, MELSEC iQ-R Series CC-Link IE TSN Master/Local Module, MELSEC iQ-R Series Ethernet Interface Module, CC-Link IE TSN Master/Local Station Communication LSI CP610, MELSEC iQ-F Series FX5 CC-Link IE TSN Master/Local Module, MELSEC iQ-F Series FX5 Ethernet Module, MELSEC iQ-F Series FX5-ENET/IP Ethernet Module, and MELSEC iQ-R Series CPU module allows a remote unauthenticated attacker to cause a Denial of Service condition in the products by sending specially crafted UDP packets. | |||||
| CVE-2023-27508 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-27503 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-23544 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-22446 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-22445 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-22437 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-22434 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-22433 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||
| CVE-2023-22430 | 2026-08-27 | N/A | N/A | ||
| Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority because it is Unused | |||||