Bug 1223767 (CVE-2024-27050) - VUL-0: CVE-2024-27050: libbpf: use OPTS_SET() macro in bpf_xdp_query()
Summary: VUL-0: CVE-2024-27050: libbpf: use OPTS_SET() macro in bpf_xdp_query()
Status: RESOLVED UPSTREAM
Alias: CVE-2024-27050
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Major
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL: https://smash.suse.de/issue/403841/
Whiteboard: CVSSv3.1:SUSE:CVE-2024-27050:7.8:(AV:...
Keywords:
Depends on:
Blocks:
 
Reported: 2024-05-02 14:36 UTC by SMASH SMASH
Modified: 2024-05-08 13:22 UTC (History)
4 users (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SMASH SMASH 2024-05-02 14:36:59 UTC
In the Linux kernel, the following vulnerability has been resolved:

libbpf: Use OPTS_SET() macro in bpf_xdp_query()

When the feature_flags and xdp_zc_max_segs fields were added to the libbpf
bpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro.
This causes libbpf to write to those fields unconditionally, which means
that programs compiled against an older version of libbpf (with a smaller
size of the bpf_xdp_query_opts struct) will have its stack corrupted by
libbpf writing out of bounds.

The patch adding the feature_flags field has an early bail out if the
feature_flags field is not part of the opts struct (via the OPTS_HAS)
macro, but the patch adding xdp_zc_max_segs does not. For consistency, this
fix just changes the assignments to both fields to use the OPTS_SET()
macro.

References:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-27050
https://www.cve.org/CVERecord?id=CVE-2024-27050
https://git.kernel.org/stable/c/682ddd62abd4bdcee7584246903e7a2df005fe0d
https://git.kernel.org/stable/c/92a871ab9fa59a74d013bc04f321026a057618e7
https://git.kernel.org/stable/c/cd3be9843247edb8fc6fcd8d8237cbce2bc19f5e
https://git.kernel.org/stable/c/fa5bef5e80c6a3321b2b1a7070436f3bc5daf07c
https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2024/CVE-2024-27050.mbox
https://bugzilla.redhat.com/show_bug.cgi?id=2278427
Comment 3 Shung-Hsi Yu 2024-05-06 12:28:18 UTC
The libbpf package we provide to customer is at SUSE:SLE-15-SP6:GA/libbpf, which is sourced from the upstream repository https://github.com/libbpf/libbpf, rather  than inheriting the source from kernel-source (since SLE-15-SP4).

SUSE:SLE-15-SP6:GA/libbpf is at v1.2.2, which is roughly equivalent to v6.5 in kernel-source, and thus does not contain the buggy commit.

> $ git log -n1 --oneline --grep='Start v1.3 development' tools/lib/bpf/libbpf.map
> 2b001b94073b libbpf: Start v1.3 development cycle
> $ git describe --tags --contains 2b001b94073b
> v6.5-rc1~163^2~215^2~10

Reassigning back to security team.
Comment 4 Shung-Hsi Yu 2024-05-06 12:29:16 UTC
For completeness, this is a bug in the user-space library libbpf, and not in the Linux kernel itself.
Comment 8 Marcus Meissner 2024-05-08 13:22:02 UTC
no libbpf version affected.