GHSA-P4MQ-5HWR-HC6R

Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2025-11-03 21:33
VLAI
Details

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

powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC

Erhard reported the following KASAN hit while booting his PowerMac G4 with a KASAN-enabled kernel 6.13-rc6:

BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293

CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000

GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00

The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================

f8 corresponds to KASAN_VMALLOC_INVALID which means the area is not initialised hence not supposed to be used yet.

Powerpc text patching infrastructure allocates a virtual memory area using get_vm_area() and flags it as VM_ALLOC. But that flag is meant to be used for vmalloc() and vmalloc() allocated memory is not supposed to be used before a call to __vmalloc_node_range() which is never called for that area.

That went undetected until commit e4137f08816b ("mm, kasan, kmsan: instrument copy_from/to_kernel_nofault")

The area allocated by text_area_cpu_up() is not vmalloc memory, it is mapped directly on demand when needed by map_kernel_page(). There is no VM flag corresponding to such usage, so just pass no flag. That way the area will be unpoisonned and usable immediately.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-21866"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-12T10:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOC\n\nErhard reported the following KASAN hit while booting his PowerMac G4\nwith a KASAN-enabled kernel 6.13-rc6:\n\n  BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8\n  Write of size 8 at addr f1000000 by task chronyd/1293\n\n  CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G        W          6.13.0-rc6-PMacG4 #2\n  Tainted: [W]=WARN\n  Hardware name: PowerMac3,6 7455 0x80010303 PowerMac\n  Call Trace:\n  [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable)\n  [c24375b0] [c0504998] print_report+0xdc/0x504\n  [c2437610] [c050475c] kasan_report+0xf8/0x108\n  [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c\n  [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8\n  [c24376c0] [c004c014] patch_instructions+0x15c/0x16c\n  [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c\n  [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac\n  [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec\n  [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478\n  [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14\n  [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4\n  [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890\n  [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420\n  [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c\n  --- interrupt: c00 at 0x5a1274\n  NIP:  005a1274 LR: 006a3b3c CTR: 005296c8\n  REGS: c2437f40 TRAP: 0c00   Tainted: G        W           (6.13.0-rc6-PMacG4)\n  MSR:  0200f932 \u003cVEC,EE,PR,FP,ME,IR,DR,RI\u003e  CR: 24004422  XER: 00000000\n\n  GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932\n  GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57\n  GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002\n  GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001\n  NIP [005a1274] 0x5a1274\n  LR [006a3b3c] 0x6a3b3c\n  --- interrupt: c00\n\n  The buggy address belongs to the virtual mapping at\n   [f1000000, f1002000) created by:\n   text_area_cpu_up+0x20/0x190\n\n  The buggy address belongs to the physical page:\n  page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30\n  flags: 0x80000000(zone=2)\n  raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001\n  raw: 00000000\n  page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n   f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n   f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  \u003ef1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n             ^\n   f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n   f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n  ==================================================================\n\nf8 corresponds to KASAN_VMALLOC_INVALID which means the area is not\ninitialised hence not supposed to be used yet.\n\nPowerpc text patching infrastructure allocates a virtual memory area\nusing get_vm_area() and flags it as VM_ALLOC. But that flag is meant\nto be used for vmalloc() and vmalloc() allocated memory is not\nsupposed to be used before a call to __vmalloc_node_range() which is\nnever called for that area.\n\nThat went undetected until commit e4137f08816b (\"mm, kasan, kmsan:\ninstrument copy_from/to_kernel_nofault\")\n\nThe area allocated by text_area_cpu_up() is not vmalloc memory, it is\nmapped directly on demand when needed by map_kernel_page(). There is\nno VM flag corresponding to such usage, so just pass no flag. That way\nthe area will be unpoisonned and usable immediately.",
  "id": "GHSA-p4mq-5hwr-hc6r",
  "modified": "2025-11-03T21:33:10Z",
  "published": "2025-03-12T12:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21866"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2d542f13d26344e3452eee77613026ce9b653065"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2e6c80423f201405fd65254e52decd21663896f3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6847b3e40bb963e57b61d1cc6fe84cb37b9d3d4c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/8d06e9208184b2851fa79a3a39d6860320c8bdf8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/97de5852058a299ba447cd9782fe96488d30108b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c905a3053518212a1017e50bd2be3bee59305bb0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d262a192d38e527faa5984629aabda2e0d1c4f54"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f8d4c5b653c1bc0df56e15658bbf64fc359adc4e"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.