CVE-2024-50162 is a vulnerability in the Linux kernel's eBPF (extended Berkeley Packet Filter) subsystem, specifically related to the BPF_MAP_TYPE_DEVMAP and the handling of the rxq pointer after a redirect operation. The issue arises because after a redirect via a devmap, the rxq pointer, which should reference the device from which the redirect originated, is not properly set. This leads to a NULL pointer dereference when BPF programs attempt to access ingress_ifindex or other fields dependent on rxq. The vulnerability manifests as a kernel NULL pointer dereference, causing a kernel oops and potential system crash. The provided kernel log excerpt shows the crash occurring in a BPF program executed after redirect, with detailed stack traces confirming the fault in the bpf_prog_after_redirect function. This bug affects Linux kernel versions around 6.11.0-rc5 and likely others using similar BPF devmap implementations. While the vulnerability does not appear to be exploitable for privilege escalation or arbitrary code execution, it can cause denial of service (DoS) by crashing the kernel. The vulnerability is triggered by crafted BPF programs that perform redirects via devmap and subsequently access the ingress_ifindex, leading to dereferencing a NULL pointer. No known exploits are reported in the wild at this time, and no CVSS score has been assigned yet. The root cause is a missing initialization of the rxq pointer after redirect, which the patch aims to fix by ensuring rxq is properly set before BPF program execution continues.

For European organizations, the primary impact of CVE-2024-50162 is the risk of denial of service on Linux systems that utilize eBPF devmap redirects, particularly in environments leveraging advanced networking features such as XDP (Express Data Path) for high-performance packet processing. This vulnerability could cause unexpected kernel crashes, leading to system downtime, service interruptions, and potential disruption of critical infrastructure relying on Linux servers or network appliances. Organizations running containerized workloads, cloud-native applications, or network functions that employ eBPF for packet filtering or redirection are especially at risk. Although this vulnerability does not appear to allow privilege escalation or remote code execution, the resulting instability could be exploited by attackers to cause persistent denial of service, impacting availability. Given the widespread use of Linux in European data centers, telecom infrastructure, and enterprise environments, the vulnerability could affect a broad range of sectors including finance, healthcare, government, and telecommunications. The lack of known exploits reduces immediate risk, but the potential for DoS in critical systems necessitates prompt attention.

1. Apply the official Linux kernel patches that address this vulnerability as soon as they become available. Monitor Linux kernel mailing lists and vendor advisories for updates. 2. For organizations using custom or long-term support (LTS) kernels, backport the patch or upgrade to a kernel version that includes the fix. 3. Audit and review BPF programs in use, especially those employing BPF_MAP_TYPE_DEVMAP and redirect operations, to identify any that access ingress_ifindex or rely on rxq pointers. Temporarily disable or restrict such BPF programs until patched kernels are deployed. 4. Implement kernel crash monitoring and alerting to detect and respond quickly to any kernel oops or crashes potentially related to this vulnerability. 5. Limit access to load and execute BPF programs to trusted users and processes only, reducing the risk of malicious or malformed BPF code triggering the issue. 6. Employ network segmentation and isolation for systems running vulnerable kernels to minimize impact scope in case of crashes. 7. Engage with Linux distribution vendors for security advisories and timely patch releases tailored to your environment. 8. Consider fallback or redundancy mechanisms for critical systems to maintain availability during patch deployment or incident response.