CVE-2024-39488: arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY

Published Jul 10, 2024
·
Updated

In the Linux kernel, the following vulnerability has been resolved:

arm64: asm-bug: Add .align 2 to the end of BUGENTRY

The Linux kernel CVE team has assigned CVE-2024-39488 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024071013-CVE-2024-39488-f796@gregkh/T

Other sources

In the Linux kernel, the following vulnerability has been resolved:

arm64: asm-bug: Add .align 2 to the end of BUGENTRY

When CONFIGDEBUGBUGVERBOSE=n, we fail to add necessary padding bytes to bugtable entries, and as a result the last entry in a bug table will be ignored, potentially leading to an unexpected panic(). All prior entries in the table will be handled correctly.

The arm64 ABI requires that struct fields of up to 8 bytes are naturally-aligned, with padding added within a struct such that struct are suitably aligned within arrays.

When CONFIGDEBUGBUGVERPOSE=y, the layout of a bugentry is:

struct bugentry { signed int bugaddrdisp; // 4 bytes signed int filedisp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes }

... with 12 bytes total, requiring 4-byte alignment.

When CONFIGDEBUGBUGVERBOSE=n, the layout of a bugentry is:

struct bugentry { signed int bugaddrdisp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes }

... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment.

When we create a bugentry in assembly, we align the start of the entry to 4 bytes, which implicitly handles padding for any prior entries. However, we do not align the end of the entry, and so when CONFIGDEBUGBUGVERBOSE=n, the final entry lacks the trailing padding bytes.

For the main kernel image this is not a problem as findbug() doesn't depend on the trailing padding bytes when searching for entries:

for (bug = startbugtable; bug < stopbugtable; ++bug) if (bugaddr == bugaddr(bug)) return bug;

However for modules, modulebugfinalize() depends on the trailing bytes when calculating the number of entries:

mod->numbugs = sechdrs[i].shsize / sizeof(struct bugentry);

... and as the last bugentry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry:

sechdrs[i].shsize == 6 sizeof(struct bugentry) == 8;

sechdrs[i].shsize / sizeof(struct bugentry) == 0;

Consequently modulefindbug() will miss the last bugentry when it does:

for (i = 0; i < mod->numbugs; ++i, ++bug) if (bugaddr == bugaddr(bug)) goto out;

... which can lead to a kenrel panic due to an unhandled bug.

This can be demonstrated with the following module:

static int init buginit(void) { WARN(1, "hello\n"); return 0; }

static void exit bugexit(void) { }

moduleinit(buginit); moduleexit(bugexit); MODULELICENSE("GPL");

... which will trigger a kernel panic when loaded:

------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] dooneinitcall+0x80/0x1c8 doinitmodule+0x60/0x218 loadmodule+0x1ba4/0x1d70 dosysinitmodule+0x198/0x1d0 arm64sysinitmodule+0x1c/0x28 invokesyscall+0x48/0x114 el0svc ---truncated---

NVD

Affected Software

16 affected componentsFixes available
redhat/kernel<4.19.316
4.19.316
redhat/kernel<5.4.278
5.4.278
redhat/kernel<5.10.219
5.10.219
redhat/kernel<5.15.161
5.15.161
redhat/kernel<6.1.93
6.1.93
redhat/kernel<6.6.33
6.6.33
redhat/kernel<6.9.4
6.9.4
redhat/kernel<6.10
6.10
debian/linux
5.10.223-15.10.234-16.1.129-16.1.135-16.12.22-16.12.25-1
Linux Linux kernel>=4.3<4.19.316
Linux Linux kernel>=4.20<5.4.278
Linux Linux kernel>=5.5<5.10.219
Linux Linux kernel>=5.11<5.15.161
Linux Linux kernel>=5.16<6.1.93
Linux Linux kernel>=6.2<6.6.33
Linux Linux kernel>=6.7<6.9.4

Event History

Jul 10, 2024
CVE Published
via MITRE·07:14 AM
Data Sourced
via MITRE·07:14 AM
Description
Data Sourced
via NVD·08:15 AM
Description
Data Sourced
via NVD·08:15 AM
RemedySeverityAffected Software
May 5, 2025
Data Sourced
via Ubuntu·12:33 AM
RemedyDescriptionSeverityAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2024-39488?

CVE-2024-39488 is categorized as a medium severity vulnerability affecting specific versions of the Linux kernel.

2

How do I fix CVE-2024-39488?

To mitigate CVE-2024-39488, upgrade the Linux kernel to one of the fixed versions, such as 4.19.317, 5.4.279, or higher.

3

What are the affected versions in CVE-2024-39488?

CVE-2024-39488 affects Linux kernel versions up to and including 4.19.316, 5.4.278, 5.10.219, 5.15.161, 6.1.93, 6.6.33, and 6.9.4.

4

Is there a patch available for CVE-2024-39488?

Yes, patches for CVE-2024-39488 are available in the latest kernel releases and should be applied.

5

Who is impacted by CVE-2024-39488?

Users and organizations running unsupported versions of the Linux kernel mentioned in CVE-2024-39488 are at risk.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203