CVE-2024-26868

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs: fix panic when nfs4_ff_layout_prepare_ds() fails<br /> <br /> We&amp;#39;ve been seeing the following panic in production<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000065<br /> PGD 2f485f067 P4D 2f485f067 PUD 2cc5d8067 PMD 0<br /> RIP: 0010:ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]<br /> Call Trace:<br /> <br /> ? __die+0x78/0xc0<br /> ? page_fault_oops+0x286/0x380<br /> ? __rpc_execute+0x2c3/0x470 [sunrpc]<br /> ? rpc_new_task+0x42/0x1c0 [sunrpc]<br /> ? exc_page_fault+0x5d/0x110<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? ff_layout_free_layoutreturn+0x110/0x110 [nfs_layout_flexfiles]<br /> ? ff_layout_cancel_io+0x3a/0x90 [nfs_layout_flexfiles]<br /> ? ff_layout_cancel_io+0x6f/0x90 [nfs_layout_flexfiles]<br /> pnfs_mark_matching_lsegs_return+0x1b0/0x360 [nfsv4]<br /> pnfs_error_mark_layout_for_return+0x9e/0x110 [nfsv4]<br /> ? ff_layout_send_layouterror+0x50/0x160 [nfs_layout_flexfiles]<br /> nfs4_ff_layout_prepare_ds+0x11f/0x290 [nfs_layout_flexfiles]<br /> ff_layout_pg_init_write+0xf0/0x1f0 [nfs_layout_flexfiles]<br /> __nfs_pageio_add_request+0x154/0x6c0 [nfs]<br /> nfs_pageio_add_request+0x26b/0x380 [nfs]<br /> nfs_do_writepage+0x111/0x1e0 [nfs]<br /> nfs_writepages_callback+0xf/0x30 [nfs]<br /> write_cache_pages+0x17f/0x380<br /> ? nfs_pageio_init_write+0x50/0x50 [nfs]<br /> ? nfs_writepages+0x6d/0x210 [nfs]<br /> ? nfs_writepages+0x6d/0x210 [nfs]<br /> nfs_writepages+0x125/0x210 [nfs]<br /> do_writepages+0x67/0x220<br /> ? generic_perform_write+0x14b/0x210<br /> filemap_fdatawrite_wbc+0x5b/0x80<br /> file_write_and_wait_range+0x6d/0xc0<br /> nfs_file_fsync+0x81/0x170 [nfs]<br /> ? nfs_file_mmap+0x60/0x60 [nfs]<br /> __x64_sys_fsync+0x53/0x90<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Inspecting the core with drgn I was able to pull this<br /> <br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0]<br /> #0 at 0xffffffffa079657a (ff_layout_cancel_io+0x3a/0x84) in ff_layout_cancel_io at fs/nfs/flexfilelayout/flexfilelayout.c:2021:27<br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0][&amp;#39;idx&amp;#39;]<br /> (u32)1<br /> &gt;&gt;&gt; prog.crashed_thread().stack_trace()[0][&amp;#39;flseg&amp;#39;].mirror_array[1].mirror_ds<br /> (struct nfs4_ff_layout_ds *)0xffffffffffffffed<br /> <br /> This is clear from the stack trace, we call nfs4_ff_layout_prepare_ds()<br /> which could error out initializing the mirror_ds, and then we go to<br /> clean it all up and our check is only for if (!mirror-&gt;mirror_ds). This<br /> is inconsistent with the rest of the users of mirror_ds, which have<br /> <br /> if (IS_ERR_OR_NULL(mirror_ds))<br /> <br /> to keep from tripping over this exact scenario. Fix this up in<br /> ff_layout_cancel_io() to make sure we don&amp;#39;t panic when we get an error.<br /> I also spot checked all the other instances of checking mirror_ds and we<br /> appear to be doing the correct checks everywhere, only unconditionally<br /> dereferencing mirror_ds when we know it would be valid.