bpf: Fix out-of-bounds read of rtt_min in sock_ops

Description

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds read of rtt_min in sock_ops A sockops prog reading skops->rtt_min never checks the sk type: on the tcp_conn_request() path sock_ops->sk is a request_sock (non-full), and the ctx rewrite casts it to a tcp_sock (full) and reads rtt_min past the end of the request_sock, returning dirty adjacent memory. SEC("sockops") int prog(struct bpf_sock_ops *skops) { switch (skops->op) { case BPF_SOCK_OPS_RWND_INIT: leak = skops->rtt_min; /* reads the request_sock OOB */ ... } } For instance one such read returned rtt_min=0xffff8881, the high half of a leaked kernel pointer. Guarding that cast is exactly what SOCK_OPS_GET_FIELD() does -- it checks is_locked_tcp_sock and returns 0 when sock_ops->sk is not a locked full socket. Every other tcp_sock field in sock_ops goes through it; rtt_min is the only one open-coded, so it skips the check. Read rtt_min through SOCK_OPS_GET_FIELD() too. rtt_min is a bit special: it is a struct minmax and we only want the current min, so pass rtt_min.s[0].v. That is equivalent to the old hand-computed offset offsetof(struct tcp_sock, rtt_min) + sizeof_field(struct minmax_sample, t) (s[0] sits at rtt_min + 0 and .v at + sizeof(.t), i.e. what minmax_get() returns), so the loaded field is unchanged and only the full-sock guard is added. The two BUILD_BUG_ON()s that protected the hand-computed offset are no longer needed. Before patch: 0: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 1: r1 = *(u32 *)(r1 +2324) ; ((tcp_sock *)sk)->rtt_min.s[0].v After patch: 0: *(u64 *)(r1 +56) = r9 1: r9 = *(u8 *)(r1 +50) ; is_locked_tcp_sock 2: if r9 == 0 goto pc+4 ; not a locked full sock -> 0 3: r9 = *(u64 *)(r1 +56) 4: r1 = *(u64 *)(r1 +0) ; r1 = skops->sk 5: r1 = *(u32 *)(r1 +2324) ; rtt_min.s[0].v 6: goto pc+2 7: r9 = *(u64 *)(r1 +56) 8: r1 = 0

Timeline

Scores

No CVSS score yet: neither the CNA, CISA nor NVD has scored this CVE. NVD status: Received.

EPSS (exploitation in 30 days)

0.21% · top 89% of all CVEs (11 Nov 2026)

The list uses the assigner's score when there is one, then CISA's, then NVD's: Not scored.

Affected products

• Linux · Linux

  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < 0c796efa919f52f788c22c79d1f1b70321696b3d
  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < fc9d0e6e9d86fbefe7b8fe6ee49f4cf102add79d
  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < fd6bf2721933d8c90bc4ce57f3e204c9295e7e3f
  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < a8a9becbac93a9f54f4d565f1f3005eb08a7912f
  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < 3a46f14e6cf375f3ca38f8f6e6524749e24ea0a8
  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < 6785313d4fac96afb21ef193610c1fa88b1a9e64
  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < cba54d142c43ec96d8c4d566f66439e8c0afded7
  • affected 44f0e43037d3a17b043843ba67610ac7c7e37db6 – < 75f8cf22463d82bb1fb0239a3d485fc8f4c8ef03

• Linux · Linux

  • affected 4.16
  • unaffected < 4.16
  • unaffected 5.10.271 – ≤ 5.10.*
  • unaffected 5.15.222 – ≤ 5.15.*
  • unaffected 6.1.189 – ≤ 6.1.*
  • unaffected 6.6.158 – ≤ 6.6.*
  • unaffected 6.12.112 – ≤ 6.12.*
  • unaffected 6.18.55 – ≤ 6.18.*
  • unaffected 7.2.9 – ≤ 7.2.*
  • unaffected 7.3 – ≤ *

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• EUVD EUVD-2026-103557 (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2026-98643](https://cveledger.app/badge/CVE-2026-98643.svg)](https://cveledger.app/cve/CVE-2026-98643)

Record last updated 19 Oct 2026, 09:23 UTC.