DEBIAN-CVE-2025-38320

In the Linux kernel, the following vulnerability has been resolved: arm64/ptrace: Fix stack-out-of-bounds read in regsgetkernelstacknth() KASAN reports a stack-out-of-bounds read in regsgetkernelstacknth(). Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regsgetkernelstacknth+0xa8/0xc8 [ 97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550 [ 97.285732] [ 97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11 [ 97.287032] Hardware name: linux,dummy-virt (DT) [ 97.287815] Call trace: [ 97.288279] dumpbacktrace+0xa0/0x128 [ 97.288946] showstack+0x20/0x38 [ 97.289551] dumpstacklvl+0x78/0xc8 [ 97.290203] printaddressdescription.constprop.0+0x84/0x3c8 [ 97.291159] printreport+0xb0/0x280 [ 97.291792] kasanreport+0x84/0xd0 [ 97.292421] _asanload8+0x9c/0xc0 [ 97.293042] regsgetkernelstacknth+0xa8/0xc8 [ 97.293835] processfetchinsn+0x770/0xa30 [ 97.294562] kprobetracefunc+0x254/0x3b0 [ 97.295271] kprobedispatcher+0x98/0xe0 [ 97.295955] kprobebreakpointhandler+0x1b0/0x210 [ 97.296774] callbreakhook+0xc4/0x100 [ 97.297451] brkhandler+0x24/0x78 [ 97.298073] dodebugexception+0xac/0x178 [ 97.298785] el1dbg+0x70/0x90 [ 97.299344] el1h64synchandler+0xcc/0xe8 [ 97.300066] el1h64sync+0x78/0x80 [ 97.300699] kernelclone+0x0/0x500 [ 97.301331] _arm64sysclone+0x70/0x90 [ 97.302084] invokesyscall+0x68/0x198 [ 97.302746] el0svccommon.constprop.0+0x11c/0x150 [ 97.303569] doel0svc+0x38/0x50 [ 97.304164] el0svc+0x44/0x1d8 [ 97.304749] el0t64synchandler+0x100/0x130 [ 97.305500] el0t64sync+0x188/0x190 [ 97.306151] [ 97.306475] The buggy address belongs to stack of task 1.sh/2550 [ 97.307461] and is located at offset 0 in frame: [ 97.308257] _sesysclone+0x0/0x138 [ 97.308910] [ 97.309241] This frame has 1 object: [ 97.309873] [48, 184) 'args' [ 97.309876] [ 97.310749] The buggy address belongs to the virtual mapping at [ 97.310749] [ffff800089270000, ffff800089279000) created by: [ 97.310749] duptaskstruct+0xc0/0x2e8 [ 97.313347] [ 97.313674] The buggy address belongs to the physical page: [ 97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a [ 97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff) [ 97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000 [ 97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 [ 97.319445] page dumped because: kasan: bad access detected [ 97.320371] [ 97.320694] Memory state around the buggy address: [ 97.321511] ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.322681] ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 97.323846] >ffff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00 [ 97.325023] ^ [ 97.325683] ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3 [ 97.326856] ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 This issue seems to be related to the behavior of some gcc compilers and was also fixed on the s390 architecture before: commit d93a855c31b7 ("s390/ptrace: Avoid KASAN false positives in regsgetkernelstacknth()") As described in that commit, regsgetkernelstacknth() has confirmed that addr is on the stack, so reading the value at *addr should be allowed. Use READONCENOCHECK() helper to silence the KASAN check for this case. [will: Use '*addr' as the argument to READONCENOCHECK()]