In the Linux kernel, the following vulnerability has been resolved:
hfs: Fix OOB Write in hfs_asc2mac
Syzbot reported a OOB Write bug:
BUG: KASAN: slab-out-of-bounds in hfs_asc2mac+0x467/0x9a0 fs/hfs/trans.c:133 Write of size 1 at addr ffff88801848314e by task syz-executor391/3632
Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 printaddressdescription+0x74/0x340 mm/kasan/report.c:284 printreport+0x107/0x1f0 mm/kasan/report.c:395 kasanreport+0xcd/0x100 mm/kasan/report.c:495 hfsasc2mac+0x467/0x9a0 fs/hfs/trans.c:133 hfscatbuildkey+0x92/0x170 fs/hfs/catalog.c:28 hfslookup+0x1ab/0x2c0 fs/hfs/dir.c:31 lookupopen fs/namei.c:3391 [inline] openlastlookups fs/namei.c:3481 [inline] pathopenat+0x10e6/0x2df0 fs/namei.c:3710 dofilp_open+0x264/0x4f0 fs/namei.c:3740
If in->len is much larger than HFSNAMELEN(31) which is the maximum length of an HFS filename, a OOB write could occur in hfsasc2mac(). In that case, when the dst reaches the boundary, the srclen is still greater than 0, which causes a OOB write. Fix this by adding a check on dstlen in while() before writing to dst address.
{
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/50xxx/CVE-2022-50747.json"
}