Linux Kernel up to 5.15.150/6.1.80/6.6.20/6.7.8 veth_disable_xdp uninitialized pointer

Summaryinfo

A vulnerability was found in Linux Kernel up to 5.15.150/6.1.80/6.6.20/6.7.8. It has been classified as problematic. This affects the function veth_disable_xdp. The manipulation leads to uninitialized pointer. This vulnerability is referenced as CVE-2024-26803. No exploit is available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 5.15.150/6.1.80/6.6.20/6.7.8. This issue affects the function veth_disable_xdp. The manipulation with an unknown input leads to a uninitialized pointer vulnerability. Using CWE to declare the problem leads to CWE-824. The product accesses or uses a pointer that has not been initialized. The impact remains unknown. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: net: veth: clear GRO when clearing XDP even when down veth sets NETIF_F_GRO automatically when XDP is enabled, because both features use the same NAPI machinery. The logic to clear NETIF_F_GRO sits in veth_disable_xdp() which is called both on ndo_stop and when XDP is turned off. To avoid the flag from being cleared when the device is brought down, the clearing is skipped when IFF_UP is not set. Bringing the device down should indeed not modify its features. Unfortunately, this means that clearing is also skipped when XDP is disabled _while_ the device is down. And there's nothing on the open path to bring the device features back into sync. IOW if user enables XDP, disables it and then brings the device up we'll end up with a stray GRO flag set but no NAPI instances. We don't depend on the GRO flag on the datapath, so the datapath won't crash. We will crash (or hang), however, next time features are sync'ed (either by user via ethtool or peer changing its config). The GRO flag will go away, and veth will try to disable the NAPIs. But the open path never created them since XDP was off, the GRO flag was a stray. If NAPI was initialized before we'll hang in napi_disable(). If it never was we'll crash trying to stop uninitialized hrtimer. Move the GRO flag updates to the XDP enable / disable paths, instead of mixing them with the ndo_open / ndo_close paths.

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2024-26803 since 02/19/2024. Technical details of the vulnerability are known, but there is no available exploit.

The vulnerability scanner Nessus provides a plugin with the ID 210815 (RHEL 9 : kernel (RHSA-2024:9315)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 5.15.151, 6.1.81, 6.6.21, 6.7.9 or 6.8 eliminates this vulnerability. Applying the patch f011c103e654/7985d73961bb/16edf51f33f5/8f7a3894e58e/fe9f801355f0 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (210815) and CERT Bund (WID-SEC-2024-0773). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Affected

• Debian Linux
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• IBM InfoSphere Guardium
• Oracle Linux
• NetApp FAS
• EMC Avamar
• Oracle VM
• NetApp AFF
• Dell NetWorker
• IBM Security Guardium
• RESF Rocky Linux
• Open Source Linux Kernel
• SolarWinds Security Event Manager
• Broadcom Brocade SANnav
• IBM Business Automation Workflow
• IBM Spectrum Protect Plus
• IBM QRadar SIEM
• Juniper Junos Space
• IBM DB2
• IBM Storage Scale System

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 5.15.150
• 6.1.0
• 6.1.1
• 6.1.2
• 6.1.3
• 6.1.4
• 6.1.5
• 6.1.6
• 6.1.7
• 6.1.8
• 6.1.9
• 6.1.10
• 6.1.11
• 6.1.12
• 6.1.13
• 6.1.14
• 6.1.15
• 6.1.16
• 6.1.17
• 6.1.18
• 6.1.19
• 6.1.20
• 6.1.21
• 6.1.22
• 6.1.23
• 6.1.24
• 6.1.25
• 6.1.26
• 6.1.27
• 6.1.28
• 6.1.29
• 6.1.30
• 6.1.31
• 6.1.32
• 6.1.33
• 6.1.34
• 6.1.35
• 6.1.36
• 6.1.37
• 6.1.38
• 6.1.39
• 6.1.40
• 6.1.41
• 6.1.42
• 6.1.43
• 6.1.44
• 6.1.45
• 6.1.46
• 6.1.47
• 6.1.48
• 6.1.49
• 6.1.50
• 6.1.51
• 6.1.52
• 6.1.53
• 6.1.54
• 6.1.55
• 6.1.56
• 6.1.57
• 6.1.58
• 6.1.59
• 6.1.60
• 6.1.61
• 6.1.62
• 6.1.63
• 6.1.64
• 6.1.65
• 6.1.66
• 6.1.67
• 6.1.68
• 6.1.69
• 6.1.70
• 6.1.71
• 6.1.72
• 6.1.73
• 6.1.74
• 6.1.75
• 6.1.76
• 6.1.77
• 6.1.78
• 6.1.79
• 6.1.80
• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.7.0
• 6.7.1
• 6.7.2
• 6.7.3
• 6.7.4
• 6.7.5
• 6.7.6
• 6.7.7
• 6.7.8

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion