CVE-2026-74684
HighCVSS 7.1Exploitation Probability (EPSS)
Low risk4th percentile - higher than 4% of all known CVEs
Summary
In the Linux kernel, the net: tap driver has a vulnerability where in tap_get_user_xdp() the virtio-net header is parsed before assigning skb->dev. When the vhost TX path passes an XDP buffer with a GSO virtio-net header and protocol set to zero, dev_parse_header_protocol() can be called with skb->dev NULL, leading to a crash.
Risk Assessment
The risk includes system crash (NULL pointer dereference) in the packet processing path, which could lead to unavailability of network services.
Recommendation
Apply the Linux kernel patch that assigns skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering in tap_get_user().
Other vulnerabilities in Linux kernel
See all- CVE-2026-99215Unknown
In the Linux kernel power supply subsystem, a use-after-free vulnerability exists. If a power supply is unregistered while its external_power_changed() callback is still running, the driver may free data that the callback is still accessing, leading to a kernel crash (NULL pointer dereference).
- CVE-2026-99210Unknown
In the Linux kernel accel/rocket driver, rocket_probe() stores the return value of rocket_device_init() in the file-scoped rdev pointer before checking whether it is an error pointer. On failure rdev remains an ERR_PTR, and a later probe can skip initialization and dereference the error pointer when reading rdev->num_cores.
- CVE-2026-99209Unknown
In the Linux kernel drm/xe driver, xe_evict_flags() reads tbo->resource->mem_type, but a BO can reach eviction with no ttm.resource, e.g. an imported dma-buf whose resource was freed during teardown. This causes a NULL pointer dereference and a kernel fault.
- CVE-2026-99208Unknown
In the Linux kernel drm/xe/oa driver, ttm_bo_type_kernel BOs are not guaranteed to be zeroed on allocation and may contain data from previously freed pages. Since the OA buffer is mmap'able by userspace, this can expose stale kernel memory contents.
- CVE-2026-99207Unknown
In the Linux kernel's scsi: target subsystem, target_do_delayed_work() acquired delayed_cmd_lock with a plain spin_lock() without disabling interrupts, while all other acquisition sites use spin_lock_irqsave(). Since commands can now complete in interrupt context (complete_type=1 with direct_compl_supp), this can cause a deadlock when a completion arrives on the same CPU where the work item holds the lock.
- CVE-2026-99205Unknown
In the Linux kernel, a race exists in sched_change_end() with __sched_setscheduler() for queued but non-running tasks. When a task's scheduling class changes (e.g., from SCHED_OTHER to SCHED_RR), rq->next_class is not updated and the need-resched indicator is not set, causing the CPU to idle despite a runnable task being present.
- CVE-2026-99200Unknown
In the Linux kernel, the hisi_femac network driver (net: hisilicon) assigns netdev_ops only after connecting the PHY. With CONFIG_NET_SHAPER enabled, phy_attach_direct() reads uninitialized netdev_ops, causing a kernel panic from a NULL pointer dereference.
- CVE-2026-99199Unknown
In the Linux kernel, the hip04_eth network driver (net: hisilicon) calls of_phy_connect() before ndev->netdev_ops is assigned. With CONFIG_NET_SHAPER enabled, phy_attach_direct() reads uninitialized netdev_ops, causing a kernel panic from a NULL pointer dereference.
- CVE-2026-99198Unknown
In the Linux kernel, the owl_emac network driver (net: ethernet: actions) calls owl_emac_phy_init(), which connects the PHY, before netdev->netdev_ops is assigned. With CONFIG_NET_SHAPER enabled, phy_attach_direct() reads uninitialized netdev_ops, causing a kernel panic from a NULL pointer dereference.
- CVE-2026-99197Unknown
In the Linux kernel, the mv643xx_eth network driver connects the PHY before dev->netdev_ops is assigned. With CONFIG_NET_SHAPER enabled, phy_attach_direct() reads uninitialized netdev_ops, causing a kernel panic from a NULL pointer dereference.
Original NVD description (English source)
In the Linux kernel, the following vulnerability has been resolved: net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp() The commit 4f61f133f354 ("net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur. However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash. Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

