p PatchFirst

PatchFirst · Latest vulnerabilities

Operating systems stack vulnerabilities · Page 5

Vulnerabilities published for Operating systems in the last 30 days: 6746. Listed in the KEV catalogue: 0.

Filter vulnerabilities
Operating systems

Vulnerabilities: 158895

  1. CVE-2026-99064

    High · CVSS 8.1EPSS 0.52%Fix available

    cipso: adjust cached option offsets when removing CIPSO

    In the Linux kernel, the following vulnerability has been resolved: cipso: adjust cached option offsets when removing CIPSO cipso_v4_skbuff_delattr() removes the CIPSO bytes but does not adjust cached offsets for options that follow them. For example, with a valid 10-byte CIPSO option followed by a seven-byte RR option, parsing records rr at offset 30. Removing CIPSO moves RR to offset 20, while the cached offset remains 30. Consumers such as ip_forward_options() and __ip_options_echo() then access the wrong bytes; the latter may interpret packet data as the option length and copy it into fixed-size option storage. Mirror cipso_v4_delop

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  2. CVE-2026-99063

    Not ratedEPSS 0.17%Fix available

    dm ioctl: don't let data_start run past the buffer

    In the Linux kernel, the following vulnerability has been resolved: dm ioctl: don't let data_start run past the buffer struct dm_ioctl has seven bytes of trailing padding, so the smallest buffer userspace is allowed to ask for, offsetof(struct dm_ioctl, data), is seven bytes shorter than sizeof(struct dm_ioctl). get_result_buffer() sets data_start to sizeof(struct dm_ioctl) without looking at how big the buffer actually is. Ask for the minimum and data_start ends up seven bytes past the end. Callers add it to data_size, and ctl_ioctl() copies that much back to userspace: BUG: KASAN: slab-out-of-bounds in _copy_to_user+0xad/0xd0 Read o

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  3. CVE-2026-99062

    Not ratedEPSS 0.17%Fix available

    vsock/virtio: account only unread bytes in read_skb()

    In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: account only unread bytes in read_skb() After a partial stream receive, rx_bytes tracks the unread suffix while buf_used and peer credit still cover the whole packet. virtio_transport_read_skb() dequeues that packet but passes pkt_len for both counters, underflowing rx_bytes. On a connected CID_LOCAL stream with an SK_SKB verdict, a 40-byte read from a 100-byte packet made SIOCINQ report -40, an empty recv return ELOOP, and poll report the empty socket readable. After verdict detach, receiving 40 bytes wrapped the counter to zero and hid those queued bytes u

    • Update to 6.12.113
    • Update to 6.12.113-1
    • Update to 6.16
    • Update to 7.2.11-1
    Published Updated
  4. CVE-2026-99061

    Not ratedEPSS 0.17%Fix available

    wifi: brcmfmac: fix P2P device removal race in brcmf_detach()

    In the Linux kernel, the following vulnerability has been resolved: wifi: brcmfmac: fix P2P device removal race in brcmf_detach() When the driver is removed while the user space process that created the P2P device (e.g. wpa_supplicant) is still exiting, the P2P device interface is removed twice and the kernel crashes. The two paths are: - wpa_supplicant, on exit, sends NL80211_CMD_DEL_INTERFACE for the P2P device. nl80211_del_interface() holds RTNL and the wiphy mutex and calls brcmf_p2p_del_vif(), which disables discovery and waits up to 1.5 s for BRCMF_E_IF_DEL. Then it calls brcmf_remove_interface(), which unregisters the

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  5. CVE-2026-99060

    Not ratedEPSS 0.17%Fix available

    wifi: mt76: mt7603: initialize global station WCID

    In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7603: initialize global station WCID mt7603 uses a driver-private global station WCID for frames that have neither a station nor a vif, including frames injected through a monitor interface. Unlike the core global WCID initialized by mt76_register_device(), this WCID is published without ever being passed to mt76_wcid_init(). Since commit 0335c034e726 ("wifi: mt76: fix race condition related to checking tx queue fill status"), mt76_tx() queues every such frame on the WCID's tx_pending or tx_offchannel queue and links its tx_list. The first injected frame ther

    • Update to 6.12.113-1
    • Update to 6.6.160
    • Update to 7.2.11-1
    Published Updated
  6. CVE-2026-99059

    High · CVSS 7.7EPSS 0.44%Fix available

    wireguard: noise: reject response consumption after intermediate initiation

    In the Linux kernel, the following vulnerability has been resolved: wireguard: noise: reject response consumption after intermediate initiation Two threads begin processing the identical response message, received twice. The first thread, A, runs. While it's running, the second one, B, gets partway through, and during that slow calculation, or even while blocking on down_write(), A completes and then also a handshake initiation that's already been queued up runs in thread C, which itself takes that same down_write(). The handshake initiation creation succeeds, and sets the state back to waiting-for-response, and calls up_write(), at which p

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  7. CVE-2026-99058

    Not ratedEPSS 0.18%Fix available

    workqueue: Fix NULL current_pwq deref in chained work check

    In the Linux kernel, the following vulnerability has been resolved: workqueue: Fix NULL current_pwq deref in chained work check current_wq_worker() only tells us that %current is a kworker. It does not guarantee that the worker is currently executing a work item, as worker->current_pwq is populated only while process_one_work() is running the work function. is_chained_work() can be reached while queueing on a draining or destroying workqueue. If a kworker outside work-item execution reaches that path, current_wq_worker() returns a worker but worker->current_pwq is NULL, and the chained-work test can fault before it emits the intended warni

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  8. CVE-2026-99057

    Not ratedEPSS 0.18%Fix available

    xen/netfront: don't leak the skb when xennet_fill_frags() fails

    In the Linux kernel, the following vulnerability has been resolved: xen/netfront: don't leak the skb when xennet_fill_frags() fails When a response chain has more slots than fit in the skb's frags, xennet_fill_frags() returns an error and xennet_poll() jumps to its error path. That path moves what's left on tmpq to errq to be freed, but the skb being filled was already dequeued from tmpq, so it's never freed. Each chain that overflows leaks the skb and the pages attached to it as frags, and the backend decides how many slots it sends. Put the skb back on tmpq before taking the error path, like the xennet_set_skb_gso() failure just above

    • Update to 4.10
    • Update to 4.15
    • Update to 4.19
    • Update to 4.5
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  9. CVE-2026-99056

    High · CVSS 7.8EPSS 0.16%Fix available

    strparser: make sure __strp_recv isn't running before tearing down the parser

    In the Linux kernel, the following vulnerability has been resolved: strparser: make sure __strp_recv isn't running before tearing down the parser The comment above strp_done() claims that if strp is stopped, strp_recv will no longer be called. That's only true if the caller has a mechanism (eg locking) to guarantee that strp_recv() calls that started before strp_stop() have completed by the time we call strp_done(). This adds a dummy lock_sock/release_sock pair to guarantee that any in-flight strp_recv() (which runs under either bh_lock_sock or lock_sock, depending if it's called from ->sk_data_ready or strp_work) has completed. Only espi

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  10. CVE-2026-99055

    Not ratedEPSS 0.17%Fix available

    tcp: reject net_iov in zerocopy receive mapping hints

    In the Linux kernel, the following vulnerability has been resolved: tcp: reject net_iov in zerocopy receive mapping hints After copying a readable prefix, receive_fallback_to_copy() asks tcp_zerocopy_set_hint_for_skb() where page mapping can resume. If the next skb is unreadable, find_next_mappable_frag() passes its net_iov fragment to can_map_frag(). skb_frag_page() returns NULL for a net_iov, but can_map_frag() dereferences it in PageCompound(). A v7.2 KASAN run on a connected TCP socket with 64 readable bytes followed by a 4096-byte NET_IOV_DMABUF fragment reported: BUG: KASAN: null-ptr-deref in can_map_frag tcp_zerocopy_receive ->

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  11. CVE-2026-99054

    High · CVSS 7.8EPSS 0.16%Fix available

    tipc: destroy topsrv workqueues before closing connections

    In the Linux kernel, the following vulnerability has been resolved: tipc: destroy topsrv workqueues before closing connections tipc_topsrv_stop() closed subscriber connections while the topology server's send and receive workqueues were still running. Socket callbacks and subscription events could then queue more work, and in-flight send/recv work could drop the last connection reference during the conn_idr walk. That race produced several teardown failures: refcount_t addition on 0 from conn_get() on a connection whose release was blocked on idr_lock, a subsequent use-after-free in tipc_conn_close(), queue_work() on an already destroyed w

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  12. CVE-2026-99053

    High · CVSS 7.8EPSS 0.17%Fix available

    tipc: hold a reference to nodes found by link name

    In the Linux kernel, the following vulnerability has been resolved: tipc: hold a reference to nodes found by link name tipc_node_find_by_name() returns a node after dropping its RCU read lock without taking a reference. The LINK_SET, LINK_GET and LINK_RESET_STATS handlers then lock and access the node, racing with timer-driven cleanup of a down peer. Generic netlink serialization does not exclude the node timer. The following interleaving can leave a handler using a freed node: CPU 0: find the node under RCU and release the node read lock CPU 1: tipc_node_timeout() clears the links and unlinks the down node CPU 1: drop the list an

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  13. CVE-2026-99052

    Not ratedEPSS 0.17%Fix available

    selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts

    In the Linux kernel, the following vulnerability has been resolved: selinux: preserve NATIVE_LABELS on already-initialized sb in set_mnt_opts When an NFSv4 filesystem exported with security_label is mounted a second time, sget_fc() returns the existing superblock and nfs_get_root() calls security_sb_set_mnt_opts() again on it. Since the superblock is already SB_INITIALIZED, selinux_set_mnt_opts() takes an early exit without setting SECURITY_LSM_NATIVE_LABELS in *set_kern_flags. nfs_get_root() then sees kflags without SECURITY_LSM_NATIVE_LABELS set and clears NFS_CAP_SECURITY_LABEL on the shared nfs_server, silently disabling per-file labeli

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  14. CVE-2026-99051

    High · CVSS 7.8EPSS 0.15%Fix available

    fsverity: RCU-delay the freeing of struct fsverity_info

    In the Linux kernel, the following vulnerability has been resolved: fsverity: RCU-delay the freeing of struct fsverity_info __fsverity_get_info() calls rhashtable_lookup_fast(), which just uses rcu_read_lock() and doesn't directly synchronize with fsverity_remove_info(). For the same inode this isn't a problem: its fsverity_info is removed only at inode eviction time or upon failure to enable verity, when the inode no longer needs its fsverity_info and it will no longer be accessed via that inode. However, this is broken and can cause a use-after-free for concurrent __fsverity_get_info() for *different* inodes. Those rely on following fs

    • Update to 7.2.11-1
    Published Updated
  15. CVE-2026-99050

    High · CVSS 7.8EPSS 0.16%Fix available

    gpio: mpsse: fix race when arming the IRQ poll worker

    In the Linux kernel, the following vulnerability has been resolved: gpio: mpsse: fix race when arming the IRQ poll worker gpio_mpsse_irq_enable() arms the poll worker before publishing it: schedule_work() runs before the worker is added to priv->workers. If gpio_mpsse_disconnect() walks the list in that window it misses the worker, and once disconnect returns, the USB core frees mpsse_priv while the orphaned gpio_mpsse_poll() work keeps accessing it, causing a use-after-free. Fix this by publishing and arming the worker in one irq_spin critical section. Teardown walks the same list under irq_spin, so a worker found on the list is guarantee

    • Update to 6.18.57
    • Update to 7.2.11-1
    Published Updated
  16. CVE-2026-99049

    Not ratedEPSS 0.17%Fix available

    gpio: xilinx: fix runtime PM leak on request error path

    In the Linux kernel, the following vulnerability has been resolved: gpio: xilinx: fix runtime PM leak on request error path pm_runtime_get_sync() leaves the usage counter incremented even when it fails, and xgpio_request() returns the error without dropping it. gpiolib does not call ->free() when ->request() fails, so xgpio_free(), which holds the only matching pm_runtime_put(), never runs. The reference is leaked and the controller can no longer runtime-suspend, so its clock stays enabled. Switch to pm_runtime_resume_and_get(), which only increments the usage counter on success.

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  17. CVE-2026-99048

    Not ratedEPSS 0.17%Fix available

    gve: fix napi_disable deadlock when attempting to disable XSK pools

    In the Linux kernel, the following vulnerability has been resolved: gve: fix napi_disable deadlock when attempting to disable XSK pools When disabling XSK pools, GVE calls the unlocked versions of napi_disable and napi_enable. However, the netdev lock has already been acquired before ndo_bpf is called because GVE supports queue management ops. Calling the unlocked versions of napi_disable/enable results in a deadlock when attempting to disable XSK pools, as the thread attempts to re-acquire a lock it already holds. Update the NAPI calls to use the locked versions. This issue was found in production.

    • Update to 7.2.11-1
    Published Updated
  18. CVE-2026-99047

    Not ratedEPSS 0.21%Fix available

    gve: fix XSK buffer leak when rings are stopped

    In the Linux kernel, the following vulnerability has been resolved: gve: fix XSK buffer leak when rings are stopped GVE does not free XSK buffers when resetting ring state as a part of stopping queues. This causes all XSK buffers which are posted to the NIC to be leaked. Free XSK buffers attached to an allocated buf_state when stopping rings. This issue was hit in production.

    • Update to 7.2.11-1
    Published Updated
  19. CVE-2026-99046

    High · CVSS 7.5EPSS 0.53%Fix available

    gve: fix XSK buffer leak on error descriptor

    In the Linux kernel, the following vulnerability has been resolved: gve: fix XSK buffer leak on error descriptor When the error bit is set in the RX completion descriptor, the buf_state and its attached buffer should be freed. In the case of AF_XDP ZC, the XSK buffer was not freed, leading to a leak. This issue was caught by LLM.

    • Update to 7.2.11-1
    Published Updated
  20. CVE-2026-99045

    Not ratedEPSS 0.18%Fix available

    ibmveth: h_free logical LAN on open-fail after register

    In the Linux kernel, the following vulnerability has been resolved: ibmveth: h_free logical LAN on open-fail after register ibmveth_open() registers the logical LAN, then allocates the RX buffer pools. A pool failure jumps to out_free_buffer_pools without h_free_logical_lan(), so PHYP still owns the buffer-list page when it is unmapped. request_irq() failure already issued the hypercall before taking the same label. Move that h_free to the shared post-register unwind so both paths deregister before the buffer list is unmapped.

    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated

Check your server

Check your installed stack and versions against the current vulnerability feeds.

Check your server →