p PatchFirst

PatchFirst · Latest vulnerabilities

Operating systems stack vulnerabilities · Page 18

Vulnerabilities published for Operating systems in the last 30 days: 6392. Listed in the KEV catalogue: 2.

Filter vulnerabilities
Operating systems

Vulnerabilities: 159106

  1. CVE-2026-98958

    Not ratedEPSS 0.17%Fix available

    wifi: mt76: account non-AQL frames per peer rather than per link

    In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: account non-AQL frames per peer rather than per link The driver increments wcid->non_aql_packets when a frame goes to the hardware queue. The completion path decrements the counter again. For an MLO peer, the hardware reports the completion on the link that it used for the transmission. This link can differ from the link that the driver queued the frame on. In that case, the increment and the decrement go to different link wcids, and the count drifts upwards until it blocks the station. Keep the count on the wcid of the primary link, like the other peer-wide s

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

    Not ratedEPSS 0.18%Fix available

    wifi: mt76: mt7915: disable rx napi when removing device

    In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: disable rx napi when removing device Unloading the mt7915e module with a MT7916 triggers multiples WARN in __netif_napi_del_locked() and in page_pool_disable_direct_recycling() because the driver does not disable the napi before destroying it. This is troublesome since on MT7916 it is required to unload the module and reinsert it with a different enable_6ghz parameter to change the frequency. The system generally becomes unstable after reinserting the module. Fix it by disabling rx napi inside mt7915e itself, even through napi rx is enabled in the mt7

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

    Not ratedEPSS 0.17%Fix available

    ASoC: adau1372: allow sleepy powerdown GPIOs

    In the Linux kernel, the following vulnerability has been resolved: ASoC: adau1372: allow sleepy powerdown GPIOs gpiod_set_value() emits a WARN when the GPIO provider indicates that it can sleep, as is typical for I2C controlled GPIO expanders. Since the powerdown GPIO is only manipulated in process context, use the _cansleep variant instead. This lets the driver use sleepy GPIOs to power off the chip.

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

    Not ratedEPSS 0.17%Fix available

    flow_dissector: avoid u16 truncation of skb->len when computing thoff

    In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of skb->len when computing thoff __skb_flow_dissect() computes key_control->thoff using: key_control->thoff = min_t(u16, nhoff, skb ? skb->len : hlen); min_t(u16, ...) casts both arguments to u16 before comparing them. Whenever skb->len (or hlen) modulo 65536 is smaller than nhoff, the truncated length wins and thoff is set to a bogus small value, even when the dissection succeeded. For example, an IPv4/TCP frame with skb->len == 65540 and nhoff == 34 gets thoff == 4, so callers such as skb_probe_transport_header() point the transpor

    • Update to 4.10
    • Update to 4.15
    • Update to 4.5
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  5. CVE-2026-98954

    Not ratedEPSS 0.17%Fix available

    net: always dissect GSO packets in __virtio_net_hdr_to_skb()

    In the Linux kernel, the following vulnerability has been resolved: net: always dissect GSO packets in __virtio_net_hdr_to_skb() Commit 9e8db5913264 ("net: avoid false positives in untrusted gso validation") added a '&& skb->network_header' check before flow-dissecting GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in __virtio_net_hdr_to_skb(), because some callers (such as tun_get_user(), tun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called virtio_net_hdr_*_to_skb() before initializing skb->network_header and skb->dev. Because __alloc_skb() and __build_skb_around() zero-initialize skb->network_header to 0 (unlike mac_he

    • Update to 4.15
    • Update to 4.20
    • Update to 4.21
    • Update to 7.2.11-1
    Published Updated
  6. CVE-2026-98953

    Not ratedEPSS 0.18%Fix available

    devlink: fix devlink_rel reference leak when notify work is pending

    In the Linux kernel, the following vulnerability has been resolved: devlink: fix devlink_rel reference leak when notify work is pending devlink_rel_nested_in_notify_work_schedule() takes a reference on the devlink_rel for the notify work and then queues the work, ignoring the return value of schedule_delayed_work(). If the work is already pending, nothing new is queued, the work runs only once and drops only one reference, so the extra one is leaked together with the devlink_rel and its index in devlink_rels. This is easy to hit. devl_register() of a nested instance queues the work, and if the instance is unregistered before the work has r

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

    High · CVSS 7.3EPSS 0.38%Fix available

    pfcp: make sure the SEID is linear before reading it

    In the Linux kernel, the following vulnerability has been resolved: pfcp: make sure the SEID is linear before reading it pfcp_encap_recv() only makes sure that the UDP header and the 4 byte PFCP header are in the linear area. When the S flag is set, pfcp_session_recv() then reads the 8 byte SEID that follows, which is not covered by the pskb_may_pull() check. A short PFCP packet with the S flag set, or one whose session header lies in a fragment, therefore makes pfcp_session_recv() read beyond the end of the packet data, and whatever it finds there is stored in the tunnel metadata that flower later classifies on. Pull up to the end of the

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

    Not ratedEPSS 0.16%Fix available

    riscv: ptrace: Zero-initialize regset buffers before copyin

    In the Linux kernel, the following vulnerability has been resolved: riscv: ptrace: Zero-initialize regset buffers before copyin user_regset_copyin() only copies `count` bytes, so a PTRACE_SETREGSET request with a short iov_len leaves the rest of the stack buffer uninitialized. In riscv_vr_set() that garbage is validated and copied into the target's vstate, and in riscv_cfi_set() it can be stored as the target's shadow stack pointer. Zero both buffers, as the get path already does.

    • Update to 6.6
    • Update to 7.2.11-1
    Published Updated
  9. CVE-2026-98950

    Not ratedEPSS 0.18%Fix available

    flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect()

    In the Linux kernel, the following vulnerability has been resolved: flow_dissector: avoid u16 truncation of hlen in bpf_flow_dissect() bpf_flow_dissect() sanitizes the offsets returned by the BPF program with clamp_t(u16, ..., hlen). If hlen is bigger than 65535, the upper bound is truncated before the comparison. For instance, with hlen == 65536, both nhoff and thoff are forced to zero, even if the program returned sane values. This is the same class of bug as the one fixed in commit 99bda1ecbd56 ("flow_dissector: avoid u16 truncation of skb->len when computing thoff"). That fix does not cover the BPF path, because __skb_flow_dissect() r

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

    Not ratedEPSS 0.17%Fix available

    drm/imagination: Fix reference and vm_bo handling in remap()

    In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Fix reference and vm_bo handling in remap() When a map overlaps part of an existing mapping, pvr_vm_gpuva_remap() splits the mapping into prev/next parts covering what the request did not take, instead of creating something new. It gets two things wrong. - A GEM reference is taken for each part but it's never needed and never dropped, so it leaks one reference per split (remap-next-in-2m in tests/imagination/pvr_vm_map.c): CRITICAL: 33558528 bytes of shmem still held after close - The parts still belong to the original object being split, but p

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

    Not ratedEPSS 0.17%Fix available

    mlxsw: spectrum_flower: Fix port range register leak in tmplt_create()

    In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_flower: Fix port range register leak in tmplt_create() mlxsw_sp_flower_tmplt_create() parses a flow_cls_offload template into a stack-local struct mlxsw_sp_acl_rule_info purely to compute rulei.values.elusage. Parsing can acquire port range registers via mlxsw_sp_flower_parse_ports_range(), but since this rulei never goes through mlxsw_sp_acl_rulei_destroy(), those registers were never released, including through chain template deletion. Factor out of mlxsw_sp_acl_rulei_destroy() the code to actually release the necessary resources and call from mlxsw_sp_fl

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

    Not ratedEPSS 0.17%Fix available

    vsock: Fix memory leak in vmci_transport_recv_dgram_cb()

    In the Linux kernel, the following vulnerability has been resolved: vsock: Fix memory leak in vmci_transport_recv_dgram_cb() During the closure of a datagram socket, the vmci_transport_recv_dgram_cb() function may be called, which will add the packets to the socket's backlog; then, after the receive queue is cleared, the __release_sock() function will move the packet back from the socket's backlog to the receive queue, which will lead to a memory leak. sock_close __sock_release __vsock_release // take ownership by user-space lock_sock_nested sock_set_flag(sk, SOCK_DEAD) vmci_transport_release

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

    Not ratedEPSS 0.16%Fix available

    drm/vc4: Disable the V3D interrupt across runtime suspend

    In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Disable the V3D interrupt across runtime suspend vc4_irq_disable() masks the V3D interrupt sources and then calls synchronize_irq() before the V3D is powered down. However, by itself, this is not enough to quiesce the interrupt handler. synchronize_irq() waits for handlers that have already set IRQD_IRQ_INPROGRESS, and for irqchips reporting IRQCHIP_STATE_ACTIVE. A GIC interrupt chip is able to mark an interrupt active as soon as a CPU acknowledges it, so there these checks cover the whole dispatch path. On RPi 0-3, however, the interrupt controller is ARMCTRL, wh

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

    High · CVSS 7.8EPSS 0.16%Fix available

    HID: steam: Rearrange teardown sequence

    In the Linux kernel, the following vulnerability has been resolved: HID: steam: Rearrange teardown sequence This fixes a narrow window during the teardown sequence where callbacks could still be scheduled during cleanup that would then have a dangling pointer to the now-freed steam struct. This also puts work canceling for rumble and mode switch in steam_unregister, as that shouldn't persist while the client hdev is open.

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

    High · CVSS 7.8EPSS 0.18%Fix available

    HID: steam: Refactor registration

    In the Linux kernel, the following vulnerability has been resolved: HID: steam: Refactor registration This refactors and simplifies the registration/unregistration flow. Since we now only perform registration when the client isn't opened anymore, the logic for handling that can be removed, and the rest of the function streamlined. We also remove the previous assumption that we have a serial number to show we're registered, replacing it with a single purpose boolean. In a previous refactor the code for unregistering a battery if later registration steps failed was accidentally left out. As a result, a lingering power_supply object could ge

    • Update to 4.20
    • Update to 6.12.113-1
    • Update to 7.2.11-1
    Published Updated
  16. CVE-2026-98942

    Not ratedEPSS 0.16%Fix available

    sched_ext: Build the cid tables privately and publish them with RCU

    In the Linux kernel, the following vulnerability has been resolved: sched_ext: Build the cid tables privately and publish them with RCU The cid tables are visible to the cid kfuncs while being modified: the first enable publishes the global pointers before filling them, ops.init_cids() overrides rewrite them in place, and re-enables rebuild them in place. A racing TRACING or SYSCALL program can read unfilled entries, including uninitialized memory in the kmalloc'd tables, or torn topo updates. Tie the tables' lifetimes to the root sched instead: each root enable builds a fresh set privately and publishes the per-table __rcu globals once th

    • Update to 7.2.10-1
    Published Updated
  17. openSUSE-SU-2026:22159-1

    Not ratedFix available

    Security update for mozilla-nss, MozillaFirefox

    This update for mozilla-nss, MozillaFirefox fixes the following issues: Update to Firefox Extended Support Release 153.5.1 ESR (MFSA 2026-112, bsc#1286385): - CVE-2026-113470: Cryptographic issue in the Security Block-lists, Allow-lists, and other State component (bsc#1286261).

    • Update to 153.5.1-160000.1.1
    • Update to 3.125-160000.3.1
    Published Updated
  18. CVE-2026-98941

    High · CVSS 7EPSS 0.14%Fix available

    ext4: don't enable large folios on encrypted inodes

    In the Linux kernel, the following vulnerability has been resolved: ext4: don't enable large folios on encrypted inodes Commit 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS") disables large folios at mount time if the "encrypt" feature is set. However, enabling that feature on a mounted filesystem circumvents that check, and writing encrypted data results in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000028 Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work RIP: 0010:ext4_finish_bio+0xf7/0x3e0 Call Trace: ext4_release_io_end+0x51/0x110 ext4_end_io_end+0x4c/0xe0 ext4_

    • Update to 7.2.10-1
    Published Updated
  19. CVE-2026-98940

    Not ratedEPSS 0.17%Fix available

    ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

    In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: lpass-cpu: use DAI table index for playback constraints The DAI ID is a hardware port ID and is not necessarily the index of the corresponding entry in variant->dai_driver. When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code currently uses dai_id to index variant->dai_driver. This is incorrect for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S DAI has ID 4 while it is the only entry in the DAI driver table. If that DAI is configured for QUAD01 and probe reaches this branch, the code writes beyond that single entry via dai_dri

    • Update to 6.12.113-1
    • Update to 7.2.10-1
    Published Updated
  20. CVE-2026-98939

    Not ratedEPSS 0.17%Fix available

    x86/mm: Drop unnecessary PMD page copy when freeing

    In the Linux kernel, the following vulnerability has been resolved: x86/mm: Drop unnecessary PMD page copy when freeing On a box with a discrete GPU, lockdep reports a possible deadlock as soon as kswapd shrinks the TTM page pool. The immediate cause is an x86 commit that added an mmap_read_lock() to kernel page protection munging code. The huge vmap code holds the same lock over a GFP_KERNEL allocation, which is a no-no now that reclaim can take it. That allocation is in a page table *free* path and ends up being for dubious purposes[1]. Basically, it tries to avoid hardware setting Accessed=1 in page table entries that are unreachable by

    • Update to 6.18.56
    • Update to 7.2.10
    • Update to 7.2.10-1
    Published Updated

Check your server

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

Check your server →