ghsa-784p-42hr-j7xp
Vulnerability from github
Published
2025-07-10 09:32
Modified
2025-07-10 09:32
Details

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

arm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()

KASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().

Call Trace: [ 97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+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] dump_backtrace+0xa0/0x128 [ 97.288946] show_stack+0x20/0x38 [ 97.289551] dump_stack_lvl+0x78/0xc8 [ 97.290203] print_address_description.constprop.0+0x84/0x3c8 [ 97.291159] print_report+0xb0/0x280 [ 97.291792] kasan_report+0x84/0xd0 [ 97.292421] __asan_load8+0x9c/0xc0 [ 97.293042] regs_get_kernel_stack_nth+0xa8/0xc8 [ 97.293835] process_fetch_insn+0x770/0xa30 [ 97.294562] kprobe_trace_func+0x254/0x3b0 [ 97.295271] kprobe_dispatcher+0x98/0xe0 [ 97.295955] kprobe_breakpoint_handler+0x1b0/0x210 [ 97.296774] call_break_hook+0xc4/0x100 [ 97.297451] brk_handler+0x24/0x78 [ 97.298073] do_debug_exception+0xac/0x178 [ 97.298785] el1_dbg+0x70/0x90 [ 97.299344] el1h_64_sync_handler+0xcc/0xe8 [ 97.300066] el1h_64_sync+0x78/0x80 [ 97.300699] kernel_clone+0x0/0x500 [ 97.301331] __arm64_sys_clone+0x70/0x90 [ 97.302084] invoke_syscall+0x68/0x198 [ 97.302746] el0_svc_common.constprop.0+0x11c/0x150 [ 97.303569] do_el0_svc+0x38/0x50 [ 97.304164] el0_svc+0x44/0x1d8 [ 97.304749] el0t_64_sync_handler+0x100/0x130 [ 97.305500] el0t_64_sync+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] __se_sys_clone+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] dup_task_struct+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 regs_get_kernel_stack_nth()")

As described in that commit, regs_get_kernel_stack_nth() has confirmed that addr is on the stack, so reading the value at *addr should be allowed. Use READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.

[will: Use '*addr' as the argument to READ_ONCE_NOCHECK()]

Show details on source website

To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-38320"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-10T09:15:25Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/ptrace: Fix stack-out-of-bounds read in regs_get_kernel_stack_nth()\n\nKASAN reports a stack-out-of-bounds read in regs_get_kernel_stack_nth().\n\nCall Trace:\n[   97.283505] BUG: KASAN: stack-out-of-bounds in regs_get_kernel_stack_nth+0xa8/0xc8\n[   97.284677] Read of size 8 at addr ffff800089277c10 by task 1.sh/2550\n[   97.285732]\n[   97.286067] CPU: 7 PID: 2550 Comm: 1.sh Not tainted 6.6.0+ #11\n[   97.287032] Hardware name: linux,dummy-virt (DT)\n[   97.287815] Call trace:\n[   97.288279]  dump_backtrace+0xa0/0x128\n[   97.288946]  show_stack+0x20/0x38\n[   97.289551]  dump_stack_lvl+0x78/0xc8\n[   97.290203]  print_address_description.constprop.0+0x84/0x3c8\n[   97.291159]  print_report+0xb0/0x280\n[   97.291792]  kasan_report+0x84/0xd0\n[   97.292421]  __asan_load8+0x9c/0xc0\n[   97.293042]  regs_get_kernel_stack_nth+0xa8/0xc8\n[   97.293835]  process_fetch_insn+0x770/0xa30\n[   97.294562]  kprobe_trace_func+0x254/0x3b0\n[   97.295271]  kprobe_dispatcher+0x98/0xe0\n[   97.295955]  kprobe_breakpoint_handler+0x1b0/0x210\n[   97.296774]  call_break_hook+0xc4/0x100\n[   97.297451]  brk_handler+0x24/0x78\n[   97.298073]  do_debug_exception+0xac/0x178\n[   97.298785]  el1_dbg+0x70/0x90\n[   97.299344]  el1h_64_sync_handler+0xcc/0xe8\n[   97.300066]  el1h_64_sync+0x78/0x80\n[   97.300699]  kernel_clone+0x0/0x500\n[   97.301331]  __arm64_sys_clone+0x70/0x90\n[   97.302084]  invoke_syscall+0x68/0x198\n[   97.302746]  el0_svc_common.constprop.0+0x11c/0x150\n[   97.303569]  do_el0_svc+0x38/0x50\n[   97.304164]  el0_svc+0x44/0x1d8\n[   97.304749]  el0t_64_sync_handler+0x100/0x130\n[   97.305500]  el0t_64_sync+0x188/0x190\n[   97.306151]\n[   97.306475] The buggy address belongs to stack of task 1.sh/2550\n[   97.307461]  and is located at offset 0 in frame:\n[   97.308257]  __se_sys_clone+0x0/0x138\n[   97.308910]\n[   97.309241] This frame has 1 object:\n[   97.309873]  [48, 184) \u0027args\u0027\n[   97.309876]\n[   97.310749] The buggy address belongs to the virtual mapping at\n[   97.310749]  [ffff800089270000, ffff800089279000) created by:\n[   97.310749]  dup_task_struct+0xc0/0x2e8\n[   97.313347]\n[   97.313674] The buggy address belongs to the physical page:\n[   97.314604] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14f69a\n[   97.315885] flags: 0x15ffffe00000000(node=1|zone=2|lastcpupid=0xfffff)\n[   97.316957] raw: 015ffffe00000000 0000000000000000 dead000000000122 0000000000000000\n[   97.318207] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\n[   97.319445] page dumped because: kasan: bad access detected\n[   97.320371]\n[   97.320694] Memory state around the buggy address:\n[   97.321511]  ffff800089277b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   97.322681]  ffff800089277b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   97.323846] \u003effff800089277c00: 00 00 f1 f1 f1 f1 f1 f1 00 00 00 00 00 00 00 00\n[   97.325023]                          ^\n[   97.325683]  ffff800089277c80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3\n[   97.326856]  ffff800089277d00: f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n\nThis issue seems to be related to the behavior of some gcc compilers and\nwas also fixed on the s390 architecture before:\n\n commit d93a855c31b7 (\"s390/ptrace: Avoid KASAN false positives in regs_get_kernel_stack_nth()\")\n\nAs described in that commit, regs_get_kernel_stack_nth() has confirmed that\n`addr` is on the stack, so reading the value at `*addr` should be allowed.\nUse READ_ONCE_NOCHECK() helper to silence the KASAN check for this case.\n\n[will: Use \u0027*addr\u0027 as the argument to READ_ONCE_NOCHECK()]",
  "id": "GHSA-784p-42hr-j7xp",
  "modified": "2025-07-10T09:32:30Z",
  "published": "2025-07-10T09:32:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38320"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/01f91d415a8375d85e0c7d3615cd4a168308bb7c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/21da6d3561f373898349ca7167c9811c020da695"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/22f935bc86bdfbde04009f05eee191d220cd8c89"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/39dfc971e42d886e7df01371cd1bef505076d84c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/422e565b7889ebfd9c8705a3fc786642afe61fca"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/64773b3ea09235168a549a195cba43bb867c4a17"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/67abac27d806e8f9d4226ec1528540cf73af673a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/92750bfe7b0d8dbcaf578c091a65eda1c5f9ad38"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.