{"id":"DEBIAN-CVE-2024-39488","details":"In the Linux kernel, the following vulnerability has been resolved:  arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY  When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes to bug_table 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 CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:  \tstruct bug_entry { \t\tsigned int      bug_addr_disp;\t// 4 bytes \t\tsigned int      file_disp;\t// 4 bytes \t\tunsigned short  line;\t\t// 2 bytes \t\tunsigned short  flags;\t\t// 2 bytes \t}  ... with 12 bytes total, requiring 4-byte alignment.  When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:  \tstruct bug_entry { \t\tsigned int      bug_addr_disp;\t// 4 bytes \t\tunsigned short  flags;\t\t// 2 bytes \t\t\u003c implicit padding \u003e\t\t// 2 bytes \t}  ... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing padding, requiring 4-byte alginment.  When we create a bug_entry 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 CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding bytes.  For the main kernel image this is not a problem as find_bug() doesn't depend on the trailing padding bytes when searching for entries:  \tfor (bug = __start___bug_table; bug \u003c __stop___bug_table; ++bug) \t\tif (bugaddr == bug_addr(bug)) \t\t\treturn bug;  However for modules, module_bug_finalize() depends on the trailing bytes when calculating the number of entries:  \tmod-\u003enum_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);  ... and as the last bug_entry lacks the necessary padding bytes, this entry will not be counted, e.g. in the case of a single entry:  \tsechdrs[i].sh_size == 6 \tsizeof(struct bug_entry) == 8;  \tsechdrs[i].sh_size / sizeof(struct bug_entry) == 0;  Consequently module_find_bug() will miss the last bug_entry when it does:  \tfor (i = 0; i \u003c mod-\u003enum_bugs; ++i, ++bug) \t\tif (bugaddr == bug_addr(bug)) \t\t\tgoto out;  ... which can lead to a kenrel panic due to an unhandled bug.  This can be demonstrated with the following module:  \tstatic int __init buginit(void) \t{ \t\tWARN(1, \"hello\\n\"); \t\treturn 0; \t}  \tstatic void __exit bugexit(void) \t{ \t}  \tmodule_init(buginit); \tmodule_exit(bugexit); \tMODULE_LICENSE(\"GPL\");  ... which will trigger a kernel panic when loaded:  \t------------[ cut here ]------------ \thello \tUnexpected kernel BRK exception at EL1 \tInternal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP \tModules linked in: hello(O+) \tCPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8 \tHardware name: linux,dummy-virt (DT) \tpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) \tpc : buginit+0x18/0x1000 [hello] \tlr : buginit+0x18/0x1000 [hello] \tsp : ffff800080533ae0 \tx29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 \tx26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 \tx23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 \tx20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 \tx17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 \tx14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 \tx11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 \tx8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 \tx5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 \tx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 \tCall trace: \t buginit+0x18/0x1000 [hello] \t do_one_initcall+0x80/0x1c8 \t do_init_module+0x60/0x218 \t load_module+0x1ba4/0x1d70 \t __do_sys_init_module+0x198/0x1d0 \t __arm64_sys_init_module+0x1c/0x28 \t invoke_syscall+0x48/0x114 \t el0_svc ---truncated---","modified":"2026-09-15T09:02:43.427073339Z","published":"2024-07-10T08:15:11.003Z","upstream":["CVE-2024-39488"],"references":[{"type":"ADVISORY","url":"https://security-tracker.debian.org/tracker/CVE-2024-39488"}],"affected":[{"package":{"name":"linux","ecosystem":"Debian:12","purl":"pkg:deb/debian/linux?arch=source&distro=bookworm"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.1.94-1"}]}],"versions":["6.1.27-1","6.1.37-1","6.1.38-1","6.1.38-2","6.1.38-2~bpo11+1","6.1.38-3","6.1.38-4","6.1.38-4~bpo11+1","6.1.52-1","6.1.55-1","6.1.55-1~bpo11+1","6.1.64-1","6.1.66-1","6.1.67-1","6.1.69-1","6.1.69-1~bpo11+1","6.1.76-1","6.1.76-1~bpo11+1","6.1.82-1","6.1.85-1","6.1.90-1","6.1.90-1~bpo11+1","6.1.94-1~bpo11+1"],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-39488.json"}},{"package":{"name":"linux","ecosystem":"Debian:13","purl":"pkg:deb/debian/linux?arch=source&distro=trixie"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-39488.json"}},{"package":{"name":"linux","ecosystem":"Debian:14","purl":"pkg:deb/debian/linux?arch=source&distro=forky"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.9.7-1"}]}],"ecosystem_specific":{"urgency":"not yet assigned"},"database_specific":{"source":"https://storage.googleapis.com/osv-test-debian-osv/debian-cve-osv/DEBIAN-CVE-2024-39488.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H"}]}