p PatchFirst

PatchFirst · Latest vulnerabilities

linux-aws-7.0 vulnerabilities · Page 188

Vulnerabilities published for linux-aws-7.0 in the last 30 days: 1031. Listed in the KEV catalogue: 0.

RSS ↗ JSON ↗
Filter vulnerabilities
Clear filters

Vulnerabilities: 5250

  1. CVE-2026-72467

    Not ratedEPSS 0.21%Fix available

    xprtrdma: Check frwr_wp_create() during connect

    In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Check frwr_wp_create() during connect frwr_wp_create() creates the singleton Memory Region used to encode padding for Write chunks whose payload length is not XDR-aligned. Its failure paths return a negative errno and leave ep->re_write_pad_mr set to NULL. rpcrdma_xprt_connect() currently ignores that return value. If frwr_wp_create() fails after the rest of the connection setup succeeds, xprt_rdma_connect_worker() treats the connection attempt as successful and sets XPRT_CONNECTED. A later NFS/RDMA read with a non-4-byte-aligned receive page length reaches rpcrd

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  2. CVE-2026-72466

    Critical · CVSS 9.8EPSS 0.74%Fix available

    xprtrdma: Fix bcall rep leak and unbounded peek

    In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix bcall rep leak and unbounded peek rpcrdma_is_bcall() decodes a reply's first words to decide whether the frame is a backchannel call. Two issues in that decode path let a short or malformed reply leak the receive buffer and drain the Receive queue. First, the speculative peek p = xdr_inline_decode(xdr, 0); /* five p++ reads follow */ asks xdr_inline_decode() for zero bytes, which returns xdr->p without consulting xdr->end. The five subsequent __be32 reads can then walk up to 20 bytes past the wire payload into stale regbuf contents and misclassify t

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1013.13~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  3. CVE-2026-72465

    High · CVSS 7.5EPSS 0.68%Fix available

    xprtrdma: Sanitize the reply credit grant after parsing

    In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Sanitize the reply credit grant after parsing The out_norqst exit in rpcrdma_reply_handler() branches away before the credit clamp, so a reply that matches no pending request reaches out_post carrying the raw credit value parsed from the wire. rpcrdma_post_recvs() does not bound its @needed argument: the refill loop allocates and chains Receive WRs until the count is satisfied or allocation fails. A peer that sends a well-formed reply carrying an unknown XID and an inflated credit grant therefore drives rep allocation and Receive posting past re_max_requests on ev

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  4. CVE-2026-72464

    High · CVSS 7.5EPSS 0.68%Fix available

    xprtrdma: Repost Receive buffers for malformed replies

    In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Repost Receive buffers for malformed replies rpcrdma_wc_receive() decrements the transport's Receive count for every completion before it dispatches a successful Receive to rpcrdma_reply_handler(). The handler must post a replacement Receive WR before returning unless ownership of the rep has moved elsewhere, as on the backchannel path. Commit 2ae50ad68cd7 ("xprtrdma: Close window between waking RPC senders and posting Receives") moved the Receive refill out of rpcrdma_wc_receive(), where it had run ahead of every reply, into rpcrdma_reply_handler() so that the r

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  5. CVE-2026-72463

    Critical · CVSS 9.8EPSS 0.44%Fix available

    xfrm: Fix dev use-after-free in xfrm async resumption

    In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix dev use-after-free in xfrm async resumption xfrm async resumption hold skb->dev refcnt until after transport_finish. However, xfrm_rcv_cb may modify skb->dev to tunnel dev without taking device reference, such as vti_rcv_cb. The subsequent async resumption will decrement the tunnel device's reference count, which lead to uaf of tunnel dev and refcnt leak of orig dev as below: unregister_netdevice: waiting for vti1 to become free. Usage count = -2 Stash the original skb->dev to fix refcnt imbalance. The new skb->dev set by xfrm_rcv_cb can race with device teardow

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1013.13~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  6. CVE-2026-72462

    High · CVSS 8.8EPSS 0.17%Fix available

    apparmor: fix race in unix socket mediation when peer_path is used

    In the Linux kernel, the following vulnerability has been resolved: apparmor: fix race in unix socket mediation when peer_path is used The holding a reference to the peer_sk is not enough to ensure access to the peer sk path. Accessing the path outside of the state lock allows for a race with unix_release_sock(). Fix this by taking the state lock and getting a reference to the path under lock. Ideally for connected sockets we would cache this information so we don't have to take the lock here. But for now just fix the race.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  7. CVE-2026-72461

    High · CVSS 7.8EPSS 0.17%Fix available

    apparmor: fix refcount leak when updating the sk_ctx

    In the Linux kernel, the following vulnerability has been resolved: apparmor: fix refcount leak when updating the sk_ctx Currently update_sk_ctx() transfers the plabel reference, unfortunately it is also unconditionally put in the caller. Ideally we would make the caller conditionally put the reference based on whether it was transferred but for now just fix the bug by getting a reference.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  8. CVE-2026-72460

    High · CVSS 7.1EPSS 0.13%Fix available

    apparmor: check label build before no_new_privs test

    In the Linux kernel, the following vulnerability has been resolved: apparmor: check label build before no_new_privs test aa_change_profile() builds a replacement label with fn_label_build_in_scope() before the no_new_privs subset check. The build helper can fail and return NULL or an ERR_PTR, but the result was passed to aa_label_is_unconfined_subset() before the existing IS_ERR_OR_NULL() check. Reuse the existing target-label build failure handling immediately after the build. This preserves the current audit handling while preventing the subset helper from dereferencing an invalid label.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  9. CVE-2026-72459

    High · CVSS 7.8EPSS 0.14%Fix available

    apparmor: aa_label_alloc use aa_label_free on alloc failure

    In the Linux kernel, the following vulnerability has been resolved: apparmor: aa_label_alloc use aa_label_free on alloc failure aa_label_alloc() allocates a secid before allocating or taking the label proxy. If the later proxy step fails, the error path only freed the label memory, leaking any resources initialized by aa_label_init(). Use aa_label_free() on the failure path so partially initialized labels release their secid and other label resources before the backing memory is freed.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  11. CVE-2026-72457

    Not ratedEPSS 0.21%Fix available

    apparmor: fail policy unpack on accept2 allocation failure

    In the Linux kernel, the following vulnerability has been resolved: apparmor: fail policy unpack on accept2 allocation failure unpack_pdb() may need to allocate a missing ACCEPT2 table for older policy data. If that allocation failed, it set an error message but jumped to the success path, returning a policydb with the required table missing. Return -ENOMEM through the normal failure path when the ACCEPT2 allocation fails. Remove the now-unused out label.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  12. CVE-2026-72456

    Not ratedEPSS 0.2%Fix available

    apparmor: release exe file resources on path failure

    In the Linux kernel, the following vulnerability has been resolved: apparmor: release exe file resources on path failure get_current_exe_path() takes both an exe_file reference and a path reference before resolving the path name. If aa_path_name() failed, it returned immediately and leaked both references. Route the failure through the common cleanup path so fput() and path_put() always run after the references are acquired.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  13. CVE-2026-72455

    High · CVSS 7.1EPSS 0.16%Fix available

    apparmor: fix uninitialised pointer passed to audit_log_untrustedstring()

    In the Linux kernel, the following vulnerability has been resolved: apparmor: fix uninitialised pointer passed to audit_log_untrustedstring() Commit 4a134723f9f1 ("apparmor: move check for aa_null file to cover all cases") intrdouced a small bug, where path_name() may pass a potentially uninitialized *name to aa_audit_file() if the path->dentry had been replaced with aa_null.dentry earlier on. This can lead to page fault like one observed on 7.0.2 openSUSE Tumbleweed kernel: [51692.242756] [ T24690] BUG: unable to handle page fault for address: 0000000f00000003 [51692.242762] [ T24690] #PF: supervisor read access in kernel mode [51692.24

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  14. CVE-2026-72454

    High · CVSS 7.8EPSS 0.17%Fix available

    i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()

    In the Linux kernel, the following vulnerability has been resolved: i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev() i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem). However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock. This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes. Remove the dependency on the bus device list and introduce a dedicated lookup table. Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock. Update the array when IBIs are en

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  15. CVE-2026-72453

    Not ratedEPSS 0.21%Fix available

    regcache: Do not overwrite error code when finalizing cache after error

    In the Linux kernel, the following vulnerability has been resolved: regcache: Do not overwrite error code when finalizing cache after error During regcache initialization, if an error occurs in the cache_ops->populate callback, and if cache operations include an exit callback, the error code from populate() is overwritten with the return value from exit(). This hides the error condition from the caller of regcache_init(), and can cause NULL pointer dereferences when the regcache is later accessed.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  16. CVE-2026-72452

    High · CVSS 7.8EPSS 0.18%Fix available

    drm/i915: clear CRTC color blob pointers after dropping refs

    In the Linux kernel, the following vulnerability has been resolved: drm/i915: clear CRTC color blob pointers after dropping refs intel_crtc_put_color_blobs() drops the CRTC color blob references, but leaves the corresponding pointers unchanged. This can matter in intel_crtc_prepare_cleared_state(), which frees the old CRTC hw state before calling intel_dp_tunnel_atomic_clear_stream_bw(). The latter can fail while looking up the DP tunnel group state, for example with -EDEADLK. If that happens, the function returns without completing the cleared state preparation. The failed atomic state will then be cleared by the atomic core and intel_cr

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  17. CVE-2026-72451

    Critical · CVSS 9.8EPSS 0.67%Fix available

    xfrm: Fix xfrm state cache insertion race

    In the Linux kernel, the following vulnerability has been resolved: xfrm: Fix xfrm state cache insertion race The xfrm input state cache insertion code checks the validity of the state before acquiring the global xfrm_state_lock. Thus it's possible for someone else to kill the state after it passed the validity check, and then the insertion will add the dead state to the cache. Fix this by moving the validity check inside the lock. This entire function is called on the input path, where BH must be off (e.g., the caller of this function xfrm_input acquires its spinlocks without disabling BH). So there is no need to disable BH here or tak

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1013.13~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  18. CVE-2026-72450

    High · CVSS 7.8EPSS 0.17%Fix available

    xfrm: validate selector family and prefixlen during match

    In the Linux kernel, the following vulnerability has been resolved: xfrm: validate selector family and prefixlen during match syzbot reported a shift-out-of-bounds in xfrm_selector_match() due to AF_UNSPEC selector with large prefixlen (e.g. 128) matched against IPv4 flow (when XFRM_STATE_AF_UNSPEC is set). Fix this by: - Rejecting mismatched families in xfrm_selector_match. - Returning false in addr4_match if prefixlen > 32. - Returning false in addr_match if prefixlen > 128 (prevents overflow).

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  19. CVE-2026-72449

    High · CVSS 7.8EPSS 0.17%Fix available

    drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm

    In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: fix list_del corruption in kfd_criu_resume_svm The cleanup tail of kfd_criu_resume_svm() walks svms->criu_svm_metadata_list and kfree()s each struct criu_svm_metadata without removing it from the list. The list head is left pointing at freed kmalloc-96 objects. A second AMDKFD_IOC_CRIU_OP from the same process re-enters: list_empty() reads the dangling ->next (use-after-free), the loop walks freed entries, and each is kfree()'d again (double-free). This is reachable by an unprivileged render-group user via /dev/kfd with no capabilities required. Add list_del()

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

  20. CVE-2026-72448

    Not ratedEPSS 0.18%Fix available

    octeontx2-pf: Fix leak of SQ timestamp buffer on teardown

    In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix leak of SQ timestamp buffer on teardown The send-queue timestamp ring is allocated with qmem_alloc() when timestamping is used, but otx2_free_sq_res() never freed sq->timestamps, leaking that memory across ifdown and device removal. Add the missing qmem_free() alongside the other SQ companion buffers.

    linux-aws-7.0Operating systems
    • Update to 7.0.0-1014.14~24.04.1
    Published Updated
    Source advisory 1 ↗Source advisory 2 ↗Source advisory 3 ↗

Check your server

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

Check your server →