CVE-2025-38502

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix oob access in cgroup local storage<br /> <br /> Lonial reported that an out-of-bounds access in cgroup local storage<br /> can be crafted via tail calls. Given two programs each utilizing a<br /> cgroup local storage with a different value size, and one program<br /> doing a tail call into the other. The verifier will validate each of<br /> the indivial programs just fine. However, in the runtime context<br /> the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the<br /> BPF program as well as any cgroup local storage flavor the program<br /> uses. Helpers such as bpf_get_local_storage() pick this up from the<br /> runtime context:<br /> <br /> ctx = container_of(current-&gt;bpf_ctx, struct bpf_cg_run_ctx, run_ctx);<br /> storage = ctx-&gt;prog_item-&gt;cgroup_storage[stype];<br /> <br /> if (stype == BPF_CGROUP_STORAGE_SHARED)<br /> ptr = &amp;READ_ONCE(storage-&gt;buf)-&gt;data[0];<br /> else<br /> ptr = this_cpu_ptr(storage-&gt;percpu_buf);<br /> <br /> For the second program which was called from the originally attached<br /> one, this means bpf_get_local_storage() will pick up the former<br /> program&amp;#39;s map, not its own. With mismatching sizes, this can result<br /> in an unintended out-of-bounds access.<br /> <br /> To fix this issue, we need to extend bpf_map_owner with an array of<br /> storage_cookie[] to match on i) the exact maps from the original<br /> program if the second program was using bpf_get_local_storage(), or<br /> ii) allow the tail call combination if the second program was not<br /> using any of the cgroup local storage maps.