{ "schema_version": "1.6.1", "id": "RPI-CVE-2026-90312", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2026-90312" ], "published": "2026-09-17T16:10:40Z", "summary": "bpf: Check load-acquire src ptr type before the load", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check load-acquire src ptr type before the load\n\ncheck_atomic_load() calls check_load_mem() before atomic_ptr_type_ok().\nFor a load-acquire that fetches into its own source register (dst_reg ==\nsrc_reg), check_load_mem() overwrites src_reg's type with the type of the\nloaded value, so the subsequent atomic_ptr_type_ok() no longer sees the\nsource pointer and fails to reject the disallowed types (ctx, pkt,\nflow_keys, sock).\n\nSince bpf_convert_ctx_accesses() does not rewrite atomic loads, the raw\naccess to the underlying kernel object is left in place. The destination\ntype is taken from the ctx access itself, so a load-acquire of the sk\nfield of struct __sk_buff for example leaves the register typed as\nPTR_TO_SOCK_COMMON_OR_NULL, which type_is_sk_pointer() does not match\neither, while it actually holds unconverted struct sk_buff bytes. Once\nthe NULL check has passed this is a type confusion, not just a leak of\nkernel data.\n\nValidate src_reg with check_reg_arg() and check the source pointer type\nwith atomic_ptr_type_ok() before the load again, mirroring\ncheck_atomic_rmw(). Out-of-range register numbers are already rejected\nearlier by check_and_resolve_insns() (commit 503d21ef8eac (\"bpf: Do\nregister range validation early\")), and the only exemption there,\nis_stack_arg_ldx(), requires BPF_LDX | BPF_MEM | BPF_DW and thus never\nmatches a BPF_ATOMIC insn. atomic_ptr_type_ok() can therefore not\ndereference register state out of bounds, that is, the out-of-bounds\nread addressed by the Fixes commit below does not reappear (as proven\nalso via selftest).", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:13", "name": "linux" }, "versions": [ "1:6.18.29-1+rpt1", "1:6.18.33-1+rpt1", "1:6.18.34-1+rpt1", "1:6.18.39-1+rpt1", "1:6.18.50-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.18.29+rpt-rpi-2712", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v6", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v7", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.29+rpt-rpi-v8-rt", "binary_version": "1:6.18.29-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-2712", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v6", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v7", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.33+rpt-rpi-v8-rt", "binary_version": "1:6.18.33-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-2712", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v6", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v7", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.34+rpt-rpi-v8-rt", "binary_version": "1:6.18.34-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-2712", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v6", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v7", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.39+rpt-rpi-v8-rt", "binary_version": "1:6.18.39-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-2712", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v6", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v7", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8", "binary_version": "1:6.18.50-1+rpt1" }, { "binary_name": "linux-image-6.18.50+rpt-rpi-v8-rt", "binary_version": "1:6.18.50-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.18.29-1+rpt1": { "linux_commit": "66318c5b5cd8145a662303af12ed39ac07eb27cc", "upstream_version": "6.18.29", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.33-1+rpt1": { "linux_commit": "95b85bebbedcaedfa7ca79116ed38b7376fba412", "upstream_version": "6.18.33", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.34-1+rpt1": { "linux_commit": "c8c7494100e99ee05b11aaa4f0588a223a63d1af", "upstream_version": "6.18.34", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.39-1+rpt1": { "linux_commit": "60ea684a8ace97bb0db1a16e20753bdd6ab371ff", "upstream_version": "6.18.39", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" }, "1:6.18.50-1+rpt1": { "linux_commit": "cff533aec2fa601846766b32ff57204e0a61bed7", "upstream_version": "6.18.50", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.18.52" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2026-90312" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/6ee7b00888498cf387dd30729e18a05328b94709" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/422a416041172af1ac610736d5f556d22b31b115" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b87803391baa7e0bef60549d8841f12e549ad057" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-09-18T17:55:42Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The attacker-controlled input is a BPF_LOAD_ACQ insn with dst_reg==src_reg in the bytecode bpf_prog_load() copies from bpf(2) BPF_PROG_LOAD (__sys_bpf). do_check_insn()\u2192check_atomic()\u2192check_atomic_load() then lets check_load_mem() overwrite the source type before atomic_ptr_type_ok(); no remote protocol message carries that insn.\nAC:L - The attacker authors a SOCKET_FILTER program that does BPF_LOAD_ACQ of offsetof(__sk_buff, sk) with dst_reg==src_reg (the PTR_TO_CTX). check_load_mem() replaces that register with PTR_TO_SOCK_COMMON_OR_NULL, so type_is_sk_pointer() does not match and atomic_ptr_type_ok() accepts it. No race or uninfluenced layout is required.\nPR:L - bpf_prog_load() allows BPF_PROG_TYPE_SOCKET_FILTER and BPF_PROG_TYPE_CGROUP_SKB without CAP_BPF when sysctl_unprivileged_bpf_disabled is 0; otherwise bpf_token_capable(CAP_BPF) is enough. bpf_token_capable() uses ns_capable() on a delegated token userns, not init-namespace root. verifier_load_acquire.c marks socket load-acquire __success_unpriv.\nUI:N - The attacker loads the program with BPF_PROG_LOAD and runs it via BPF_PROG_TEST_RUN (bpf_prog_test_run_skb on sk_filter_prog_ops) or attaches it to their own socket with setsockopt(SO_ATTACH_BPF)\u2192sk_attach_bpf() and triggers the filter. No other user must mount or open a file.\nS:U - check_atomic_load()'s type confusion and the later interpreter/JIT smp_load_acquire plus bpf_sock_convert_ctx_access loads run in the host kernel that accepted the program. That is in-kernel privilege escalation, not a KVM/Xen guest-to-host escape or IOMMU bypass.\nC:H - bpf_convert_ctx_accesses() does not rewrite BPF_ATOMIC, so load-acquire of offsetof(__sk_buff, sk) reads unconverted sk_buff bytes while the register is typed PTR_TO_SOCK_COMMON_OR_NULL. After a NULL check, later LDX of bpf_sock fields is rewritten by bpf_sock_convert_ctx_access() into struct sock loads against that pointer.\nI:H - The same confused PTR_TO_SOCK_COMMON is accepted as ARG_PTR_TO_SOCK_COMMON by bpf_sk_fullsock and, on CGROUP_SKB, bpf_sk_storage_get, which dereference and update sock-shaped kernel state on an object that is actually raw sk_buff memory. Commit-described verifier type confusion, not a bounded scalar leak.\nA:H - Interpreter BPF_LOAD_ACQ does smp_load_acquire of the unconverted ctx address, and follow-on bpf_sock_convert_ctx_access LDXes dereference that value as struct sock. A non-pointer or unmapped value page-faults in kernel context; the attacker can repeat this via BPF_PROG_TEST_RUN or the attached filter." } } }