{ "schema_version": "1.6.1", "id": "RPI-CVE-2025-40245", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2025-40245" ], "published": "2025-12-04T15:33:57Z", "summary": "nios2: ensure that memblock.current_limit is set when setting pfn limits", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnios2: ensure that memblock.current_limit is set when setting pfn limits\n\nOn nios2, with CONFIG_FLATMEM set, the kernel relies on\nmemblock_get_current_limit() to determine the limits of mem_map, in\nparticular for max_low_pfn.\nUnfortunately, memblock.current_limit is only default initialized to\nMEMBLOCK_ALLOC_ANYWHERE at this point of the bootup, potentially leading\nto situations where max_low_pfn can erroneously exceed the value of\nmax_pfn and, thus, the valid range of available DRAM.\n\nThis can in turn cause kernel-level paging failures, e.g.:\n\n[ 76.900000] Unable to handle kernel paging request at virtual address 20303000\n[ 76.900000] ea = c0080890, ra = c000462c, cause = 14\n[ 76.900000] Kernel panic - not syncing: Oops\n[ 76.900000] ---[ end Kernel panic - not syncing: Oops ]---\n\nThis patch fixes this by pre-calculating memblock.current_limit\nbased on the upper limits of the available memory ranges via\nadjust_lowmem_bounds, a simplified version of the equivalent\nimplementation within the arm architecture.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.47-1+rpt4" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" } ] }, "database_specific": { "per_version": { "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.158", "compiled_filter": false } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2025-40245" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/25f09699edd360b534ccae16bc276c3b52c471f3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5c3e38a367822f036227dd52bac82dc4a05157e2" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/b1ec9faef7e36269ca3ec890972a78effbaeb975" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/90f5f715550e07cd6a51f80fc3f062d832c8c997" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/8912814f14e298b83df072fecc1f7ed1b63b1b2c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/a20b83cf45be2057f3d073506779e52c7fa17f94" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T12:19:11Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The defect is in nios2 `setup_arch()` boot-time memory initialization, and its consequences are realized through local activity \u2014 memory allocation and `mmap()`/page-fault paths that call `pfn_valid()`/`pfn_to_page()`. There is no network or remote-peer path to arch/nios2/kernel/setup.c.\nAC:L - `memblock.current_limit` is never set before `find_limits()`, so `max_low_pfn`/`max_mapnr` are unconditionally inflated to ~4 GB of PFNs on every affected nios2 system \u2014 the vulnerable state always exists, with no race and no memory-layout luck required. The attacker only needs to map or touch a physical region above DRAM, which is under their control on these FPGA SoCs where peripheral/on-chip-memory windows sit above RAM.\nPR:L - No capability check guards any of it \u2014 an ordinary unprivileged process reaching `update_mmu_cache_range()`/`flush_dcache_page()` through a fault on a device or PFNMAP mapping, or simply driving allocation into the bogus PFN range, is sufficient. Embedded nios2 deployments routinely expose UIO/framebuffer device nodes to non-root users.\nUI:N - The attacker performs every step themselves \u2014 map the region, touch it, let the fault path run. No action by another user or administrator is needed.\nS:U - The out-of-bounds accesses stay within the kernel's own memory and security authority; no VM, IOMMU, or sandbox boundary is crossed.\nC:H - `pfn_valid()` wrongly approves PFNs with no memmap entry, so `pfn_to_page()` returns a pointer up to tens of megabytes past the end of `mem_map`, and `folio_flush_mapping()`/`flush_aliases()` read and follow that out-of-bounds kernel data as an `address_space`. This is a wide, PFN-indexed out-of-bounds read, far beyond a strictly bounded few bytes.\nI:H - `update_mmu_cache_range()` performs `test_and_set_bit(PG_dcache_clean, &folio->flags.f)` on the out-of-bounds `struct page`, an attacker-positioned out-of-bounds atomic write into arbitrary kernel memory, and then walks a garbage `address_space`/i_mmap tree. Per the OOB-write guidance this is High.\nA:H - The documented, reproduced impact is a fatal kernel paging fault and panic (\"Unable to handle kernel paging request ... Kernel panic - not syncing: Oops\"), and the corrupted low-memory limits can equally cause the allocator and DMA logic to operate on non-existent DRAM. The condition is triggerable repeatedly at will." } } }