{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-26868", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-26868" ], "published": "2024-04-17T10:29:01Z", "summary": "nfs: fix panic when nfs4_ff_layout_prepare_ds() fails", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: fix panic when nfs4_ff_layout_prepare_ds() fails\n\nWe've been seeing the following panic in production\n\nBUG: kernel NULL pointer dereference, address: 0000000000000065\nPGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0\nRIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]\nCall Trace:\n \n ? __die+0x78/0xc0\n ? page_fault_oops+0x286/0x380\n ? __rpc_execute+0x2c3/0x470 [sunrpc]\n ? rpc_new_task+0x42/0x1c0 [sunrpc]\n ? exc_page_fault+0x5d/0x110\n ? asm_exc_page_fault+0x22/0x30\n ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]\n ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]\n ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]\n pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]\n pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]\n ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]\n nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]\n ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]\n __nfs_pageio_add_request+0x154/0x6c0 [nfs]\n nfs_pageio_add_request+0x26b/0x380 [nfs]\n nfs_do_writepage+0x111/0x1e0 [nfs]\n nfs_writepages_callback+0xf/0x30 [nfs]\n write_cache_pages+0x17f/0x380\n ? nfs_pageio_init_write+0x50/0x50 [nfs]\n ? nfs_writepages+0x6d/0x210 [nfs]\n ? nfs_writepages+0x6d/0x210 [nfs]\n nfs_writepages+0x125/0x210 [nfs]\n do_writepages+0x67/0x220\n ? generic_perform_write+0x14b/0x210\n filemap_fdatawrite_wbc+0x5b/0x80\n file_write_and_wait_range+0x6d/0xc0\n nfs_file_fsync+0x81/0x170 [nfs]\n ? nfs_file_mmap+0x60/0x60 [nfs]\n __x64_sys_fsync+0x53/0x90\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nInspecting the core with drgn I was able to pull this\n\n >>> prog.crashed_thread().stack_trace()[0]\n #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27\n >>> prog.crashed_thread().stack_trace()[0]['idx']\n (u32)1\n >>> prog.crashed_thread().stack_trace()[0]['flseg'].mirror_array[1].mirror_ds\n (struct nfs4_ff_layout_ds *)0xffffffffffffffed\n\nThis is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()\nwhich could error out initializing the mirror_ds, and then we go to\nclean it all up and our check is only for if (!mirror->mirror_ds). This\nis inconsistent with the rest of the users of mirror_ds, which have\n\n if (IS_ERR_OR_NULL(mirror_ds))\n\nto keep from tripping over this exact scenario. Fix this up in\nff_layout_cancel_io() to make sure we don't panic when we get an error.\nI also spot checked all the other instances of checking mirror_ds and we\nappear to be doing the correct checks everywhere, only unconditionally\ndereferencing mirror_ds when we know it would be valid.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v6", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "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" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v6", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7l", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v6", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7l", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v6", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7l", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v6", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7l", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.83" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.83" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.83" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.23" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-26868" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/31db25e3141b20e2a76a9f219eeca52e3cab126c" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/7ca651b4ec4a049f5a46a0e5ff921b86b91c47c5" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/5ada9016b1217498fad876a3d5b07645cc955608" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/dac068f164ad05b35e7c0be13f138c3f6adca58f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/719fcafe07c12646691bd62d7f8d94d657fa0766" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.5, "cvss_v3_severity": "High", "scenario": "AV:N - The vulnerable code path is driven entirely by data from the remote NFS server \u2014 a malicious, compromised, or spoofed NFSv4.1/4.2 server forces GETDEVICEINFO to fail (error reply, malformed XDR, or no usable DS addresses), which is what plants the ERR_PTR that is later dereferenced. The NFS client processes this attacker-controlled protocol data over the network with no locality restriction.\nAC:L - The server-side attacker fully and deterministically controls the trigger: grant a flexfiles layout, then fail the GETDEVICEINFO for one of its device IDs, and the very next write/fsync on that inode panics the client. No race, no memory-layout grooming, and the flexfiles layout driver is present in default distro NFSv4.1 configurations.\nPR:N - The attacker acts as the NFS server (or an RPC-reply injector on the path) and needs no credentials or account on the victim client. Even in the purely local framing, any unprivileged user with write access to a file on the mount reaches nfs_writepages()\u2192ff_layout_pg_init_write(), so no elevated privileges are required in any scenario.\nUI:N - No victim action is needed at exploit time \u2014 the mount is pre-existing infrastructure, and normal background writeback or any application fsync() drives the path automatically. A compromised server can simply wait for routine client I/O.\nS:U - The fault occurs in the NFS client within the kernel's own security authority; nothing crosses into another VM, hypervisor, or IOMMU/DMA boundary.\nC:N - The dereferenced value can only ever be ERR_PTR(-ENODEV), producing a fixed low address (0x65) below mmap_min_addr that faults immediately. No attacker data is read back and no kernel memory is disclosed.\nI:N - The bug is a read of an invalid fixed pointer with no write to kernel memory and no attacker influence over the faulting address, so there is no data modification or control-flow hijack primitive.\nA:H - The result is an unrecoverable kernel NULL-pointer dereference oops in writeback context (as captured in the production panic in the fix commit), taking down the client system. It can be re-triggered at will by the remote server, so affected clients can be kept permanently down." } } }