In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: fix buffer overflow detection when copying path to cache entry
Starting with commit c0247d289e73 ("btrfs: send: annotate struct namecacheentry with __countedby()") we annotated the variable length array "name" from the namecache_entry structure with __countedby() to improve overflow detection. However that alone was not correct, because the length of that array does not match the "namelen" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this:
strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortifyreport+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC23.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: <TASK> ? __warn+0x12a/0x1d0 ? __fortifyreport+0x45/0x50 ? reportbug+0x154/0x1c0 ? handlebug+0x42/0x70 ? excinvalidop+0x1a/0x50 ? asmexcinvalidop+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __getcurnameandparent+0x3bc/0x3c0 getcurpath+0x207/0x3b0 sendextentdata+0x709/0x10d0 ? findparentnodes+0x22df/0x25d0 ? masnomem+0x13/0x90 ? mtreeinsertrange+0xa5/0x110 ? btrfslrucachestore+0x5f/0x1e0 ? iterateextentinodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfxlookupbackref_cache+0x10/0x10 ? __pfxstorebackref_cache+0x10/0x10 ? __pfxiteratebackrefs+0x10/0x10 ? __pfxcheckextentitem+0x10/0x10 changedcb+0x6fa/0x930 ? treeadvance+0x362/0x390 ? memcmpextentbuffer+0xd7/0x160 sendsubvol+0xf0a/0x1520 btrfsioctlsend+0x106b/0x11d0 ? pfxclonerootcmpsort+0x10/0x10 btrfsioctlsend+0x1ac/0x240 btrfsioctl+0x75b/0x850 __sesysioctl+0xca/0x150 dosyscall64+0x85/0x160 ? __countmemcgevents+0x69/0x100 ? handlemmfault+0x1327/0x15c0 ? _sesysrtsigprocmask+0xf1/0x180 ? syscallexittousermode+0x75/0xa0 ? dosyscall64+0x91/0x160 ? douseraddrfault+0x21d/0x630 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 </TASK>
Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way "name_len" corresponds to the actual size of the "name" array. This requires marking the "name" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at:
https://github.com/KSPP/linux/issues/90
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/49xxx/CVE-2024-49869.json"
}