Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/core: Fix ib_cache_setup_one error flow cleanup<br /> <br /> When ib_cache_update return an error, we exit ib_cache_setup_one<br /> instantly with no proper cleanup, even though before this we had<br /> already successfully done gid_table_setup_one, that results in<br /> the kernel WARN below.<br /> <br /> Do proper cleanup using gid_table_cleanup_one before returning<br /> the err in order to fix the issue.<br /> <br /> WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0<br /> Modules linked in:<br /> CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:gid_table_release_one+0x181/0x1a0<br /> Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41<br /> RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527<br /> RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001<br /> RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631<br /> R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001<br /> R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001<br /> FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? show_regs+0x94/0xa0<br /> ? __warn+0x9e/0x1c0<br /> ? gid_table_release_one+0x181/0x1a0<br /> ? report_bug+0x1f9/0x340<br /> ? gid_table_release_one+0x181/0x1a0<br /> ? handle_bug+0xa2/0x110<br /> ? exc_invalid_op+0x31/0xa0<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __warn_printk+0xc7/0x180<br /> ? __warn_printk+0xd4/0x180<br /> ? gid_table_release_one+0x181/0x1a0<br /> ib_device_release+0x71/0xe0<br /> ? __pfx_ib_device_release+0x10/0x10<br /> device_release+0x44/0xd0<br /> kobject_put+0x135/0x3d0<br /> put_device+0x20/0x30<br /> rxe_net_add+0x7d/0xa0<br /> rxe_newlink+0xd7/0x190<br /> nldev_newlink+0x1b0/0x2a0<br /> ? __pfx_nldev_newlink+0x10/0x10<br /> rdma_nl_rcv_msg+0x1ad/0x2e0<br /> rdma_nl_rcv_skb.constprop.0+0x176/0x210<br /> netlink_unicast+0x2de/0x400<br /> netlink_sendmsg+0x306/0x660<br /> __sock_sendmsg+0x110/0x120<br /> ____sys_sendmsg+0x30e/0x390<br /> ___sys_sendmsg+0x9b/0xf0<br /> ? kstrtouint+0x6e/0xa0<br /> ? kstrtouint_from_user+0x7c/0xb0<br /> ? get_pid_task+0xb0/0xd0<br /> ? proc_fail_nth_write+0x5b/0x140<br /> ? __fget_light+0x9a/0x200<br /> ? preempt_count_add+0x47/0xa0<br /> __sys_sendmsg+0x61/0xd0<br /> do_syscall_64+0x50/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds<br /> <br /> In the function init_conns(), after the create_con() and create_cm() for<br /> loop if something fails. In the cleanup for loop after the destroy tag, we<br /> access out of bound memory because cid is set to clt_path-&gt;s.con_num.<br /> <br /> This commits resets the cid to clt_path-&gt;s.con_num - 1, to stay in bounds<br /> in the cleanup loop later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency<br /> <br /> In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to<br /> destroying CM IDs"), the function flush_workqueue is invoked to flush the<br /> work queue iwcm_wq.<br /> <br /> But at that time, the work queue iwcm_wq was created via the function<br /> alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.<br /> <br /> Because the current process is trying to flush the whole iwcm_wq, if<br /> iwcm_wq doesn&amp;#39;t have the flag WQ_MEM_RECLAIM, verify that the current<br /> process is not reclaiming memory or running on a workqueue which doesn&amp;#39;t<br /> have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee<br /> leading to a deadlock.<br /> <br /> The call trace is as below:<br /> <br /> [ 125.350876][ T1430] Call Trace:<br /> [ 125.356281][ T1430] <br /> [ 125.361285][ T1430] ? __warn (kernel/panic.c:693)<br /> [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))<br /> [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)<br /> [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)<br /> [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))<br /> [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)<br /> [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))<br /> [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))<br /> [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)<br /> [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)<br /> [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm<br /> [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)<br /> [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)<br /> [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)<br /> [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm<br /> [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma<br /> [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma<br /> [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)<br /> [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)<br /> [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)<br /> [ 125.531837][ T1430] kthread (kernel/kthread.c:389)<br /> [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)<br /> [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)<br /> [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)<br /> [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)<br /> [ 125.566487][ T1430] <br /> [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error<br /> <br /> Ensure index in rtl2830_pid_filter does not exceed 31 to prevent<br /> out-of-bounds access.<br /> <br /> dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should<br /> only operate on indices from 0 to 31. If index is 32, it will attempt to<br /> access a non-existent 33rd bit, leading to out-of-bounds access.<br /> Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error<br /> <br /> Ensure index in rtl2832_pid_filter does not exceed 31 to prevent<br /> out-of-bounds access.<br /> <br /> dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should<br /> only operate on indices from 0 to 31. If index is 32, it will attempt to<br /> access a non-existent 33rd bit, leading to out-of-bounds access.<br /> Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this<br /> issue.<br /> <br /> [hverkuil: added fixes tag, rtl2830_pid_filter -&gt; rtl2832_pid_filter in logmsg]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()<br /> <br /> Patch series "nilfs2: fix potential issues with empty b-tree nodes".<br /> <br /> This series addresses three potential issues with empty b-tree nodes that<br /> can occur with corrupted filesystem images, including one recently<br /> discovered by syzbot.<br /> <br /> <br /> This patch (of 3):<br /> <br /> If a b-tree is broken on the device, and the b-tree height is greater than<br /> 2 (the level of the root node is greater than 1) even if the number of<br /> child nodes of the b-tree root is 0, a NULL pointer dereference occurs in<br /> nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().<br /> <br /> This is because, when the number of child nodes of the b-tree root is 0,<br /> nilfs_btree_do_lookup() does not set the block buffer head in any of<br /> path[x].bp_bh, leaving it as the initial value of NULL, but if the level<br /> of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(),<br /> which accesses the buffer memory of path[x].bp_bh, is called.<br /> <br /> Fix this issue by adding a check to nilfs_btree_root_broken(), which<br /> performs sanity checks when reading the root node from the device, to<br /> detect this inconsistency.<br /> <br /> Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause<br /> early on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid OOB when system.data xattr changes underneath the filesystem<br /> <br /> When looking up for an entry in an inlined directory, if e_value_offs is<br /> changed underneath the filesystem by some change in the block device, it<br /> will lead to an out-of-bounds access that KASAN detects as an UAF.<br /> <br /> EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none.<br /> loop0: detected capacity change from 2048 to 2047<br /> ==================================================================<br /> BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500<br /> Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103<br /> <br /> CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500<br /> ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697<br /> __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573<br /> ext4_lookup_entry fs/ext4/namei.c:1727 [inline]<br /> ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795<br /> lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633<br /> filename_create+0x297/0x540 fs/namei.c:3980<br /> do_symlinkat+0xf9/0x3a0 fs/namei.c:4587<br /> __do_sys_symlinkat fs/namei.c:4610 [inline]<br /> __se_sys_symlinkat fs/namei.c:4607 [inline]<br /> __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f3e73ced469<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a<br /> RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469<br /> RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0<br /> RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290<br /> R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c<br /> R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0<br /> <br /> <br /> Calling ext4_xattr_ibody_find right after reading the inode with<br /> ext4_get_inode_loc will lead to a check of the validity of the xattrs,<br /> avoiding this problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: check discard support for conventional zones<br /> <br /> As the helper function f2fs_bdev_support_discard() shows, f2fs checks if<br /> the target block devices support discard by calling<br /> bdev_max_discard_sectors() and bdev_is_zoned(). This check works well<br /> for most cases, but it does not work for conventional zones on zoned<br /> block devices. F2fs assumes that zoned block devices support discard,<br /> and calls __submit_discard_cmd(). When __submit_discard_cmd() is called<br /> for sequential write required zones, it works fine since<br /> __submit_discard_cmd() issues zone reset commands instead of discard<br /> commands. However, when __submit_discard_cmd() is called for<br /> conventional zones, __blkdev_issue_discard() is called even when the<br /> devices do not support discard.<br /> <br /> The inappropriate __blkdev_issue_discard() call was not a problem before<br /> the commit 30f1e7241422 ("block: move discard checks into the ioctl<br /> handler") because __blkdev_issue_discard() checked if the target devices<br /> support discard or not. If not, it returned EOPNOTSUPP. After the<br /> commit, __blkdev_issue_discard() no longer checks it. It always returns<br /> zero and sets NULL to the given bio pointer. This NULL pointer triggers<br /> f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the<br /> commands below at the umount step, where /dev/nullb0 is a zoned null_blk<br /> with 5GB total size, 128MB zone size and 10 conventional zones.<br /> <br /> $ mkfs.f2fs -f -m /dev/nullb0<br /> $ mount /dev/nullb0 /mnt<br /> $ for ((i=0;i

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he<br /> <br /> Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he<br /> routine adding an sta interface to the mt7996 driver.<br /> <br /> Found by code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa/mlx5: Fix invalid mr resource destroy<br /> <br /> Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr<br /> resources which never got initialized in the first place.<br /> <br /> This patch adds the missing check in mlx5_vdpa_destroy_mr_resources()<br /> to block releasing non-initialized mr resources.<br /> <br /> Reference trace:<br /> <br /> mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned?<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 140216067 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb]<br /> Code: [...]<br /> RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246<br /> RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000<br /> RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670<br /> R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000<br /> R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea<br /> FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? show_trace_log_lvl+0x1c4/0x2df<br /> ? show_trace_log_lvl+0x1c4/0x2df<br /> ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa]<br /> ? __die_body.cold+0x8/0xd<br /> ? page_fault_oops+0x134/0x170<br /> ? __irq_work_queue_local+0x2b/0xc0<br /> ? irq_work_queue+0x2c/0x50<br /> ? exc_page_fault+0x62/0x150<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa]<br /> ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb]<br /> mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa]<br /> vdpa_release_dev+0x1e/0x50 [vdpa]<br /> device_release+0x31/0x90<br /> kobject_cleanup+0x37/0x130<br /> mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa]<br /> vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa]<br /> genl_family_rcv_msg_doit+0xd9/0x130<br /> genl_family_rcv_msg+0x14d/0x220<br /> ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]<br /> ? _copy_to_user+0x1a/0x30<br /> ? move_addr_to_user+0x4b/0xe0<br /> genl_rcv_msg+0x47/0xa0<br /> ? __import_iovec+0x46/0x150<br /> ? __pfx_genl_rcv_msg+0x10/0x10<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x245/0x370<br /> netlink_sendmsg+0x206/0x440<br /> __sys_sendto+0x1dc/0x1f0<br /> ? do_read_fault+0x10c/0x1d0<br /> ? do_pte_missing+0x10d/0x190<br /> __x64_sys_sendto+0x20/0x30<br /> do_syscall_64+0x5c/0xf0<br /> ? __count_memcg_events+0x4f/0xb0<br /> ? mm_account_fault+0x6c/0x100<br /> ? handle_mm_fault+0x116/0x270<br /> ? do_user_addr_fault+0x1d6/0x6a0<br /> ? do_syscall_64+0x6b/0xf0<br /> ? clear_bhb_loop+0x25/0x80<br /> ? clear_bhb_loop+0x25/0x80<br /> ? clear_bhb_loop+0x25/0x80<br /> ? clear_bhb_loop+0x25/0x80<br /> ? clear_bhb_loop+0x25/0x80<br /> entry_SYSCALL_64_after_hwframe+0x78/0x80

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver core: Fix a potential null-ptr-deref in module_add_driver()<br /> <br /> Inject fault while probing of-fpga-region, if kasprintf() fails in<br /> module_add_driver(), the second sysfs_remove_link() in exit path will cause<br /> null-ptr-deref as below because kernfs_name_hash() will call strlen() with<br /> NULL driver_name.<br /> <br /> Fix it by releasing resources based on the exit path sequence.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> Mem abort info:<br /> ESR = 0x0000000096000005<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x05: level 1 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [dfffffc000000000] address between user and kernel address ranges<br /> Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region]<br /> CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295<br /> Hardware name: linux,dummy-virt (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : strlen+0x24/0xb0<br /> lr : kernfs_name_hash+0x1c/0xc4<br /> sp : ffffffc081f97380<br /> x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0<br /> x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000<br /> x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000<br /> x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42<br /> x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d<br /> x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000<br /> x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001<br /> x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000<br /> Call trace:<br /> strlen+0x24/0xb0<br /> kernfs_name_hash+0x1c/0xc4<br /> kernfs_find_ns+0x118/0x2e8<br /> kernfs_remove_by_name_ns+0x80/0x100<br /> sysfs_remove_link+0x74/0xa8<br /> module_add_driver+0x278/0x394<br /> bus_add_driver+0x1f0/0x43c<br /> driver_register+0xf4/0x3c0<br /> __platform_driver_register+0x60/0x88<br /> of_fpga_region_init+0x20/0x1000 [of_fpga_region]<br /> do_one_initcall+0x110/0x788<br /> do_init_module+0x1dc/0x5c8<br /> load_module+0x3c38/0x4cac<br /> init_module_from_file+0xd4/0x128<br /> idempotent_init_module+0x2cc/0x528<br /> __arm64_sys_finit_module+0xac/0x100<br /> invoke_syscall+0x6c/0x258<br /> el0_svc_common.constprop.0+0x160/0x22c<br /> do_el0_svc+0x44/0x5c<br /> el0_svc+0x48/0xb8<br /> el0t_64_sync_handler+0x13c/0x158<br /> el0t_64_sync+0x190/0x194<br /> Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to don&amp;#39;t set SB_RDONLY in f2fs_handle_critical_error()<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177<br /> CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0<br /> Workqueue: events destroy_super_work<br /> RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177<br /> Call Trace:<br /> percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42<br /> destroy_super_work+0xec/0x130 fs/super.c:282<br /> process_one_work kernel/workqueue.c:3231 [inline]<br /> process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312<br /> worker_thread+0x86d/0xd40 kernel/workqueue.c:3390<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> As Christian Brauner pointed out [1]: the root cause is f2fs sets<br /> SB_RDONLY flag in internal function, rather than setting the flag<br /> covered w/ sb-&gt;s_umount semaphore via remount procedure, then below<br /> race condition causes this bug:<br /> <br /> - freeze_super()<br /> - sb_wait_write(sb, SB_FREEZE_WRITE)<br /> - sb_wait_write(sb, SB_FREEZE_PAGEFAULT)<br /> - sb_wait_write(sb, SB_FREEZE_FS)<br /> - f2fs_handle_critical_error<br /> - sb-&gt;s_flags |= SB_RDONLY<br /> - thaw_super<br /> - thaw_super_locked<br /> - sb_rdonly() is true, so it skips<br /> sb_freeze_unlock(sb, SB_FREEZE_FS)<br /> - deactivate_locked_super<br /> <br /> Since f2fs has almost the same logic as ext4 [2] when handling critical<br /> error in filesystem if it mounts w/ errors=remount-ro option:<br /> - set CP_ERROR_FLAG flag which indicates filesystem is stopped<br /> - record errors to superblock<br /> - set SB_RDONLY falg<br /> Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the<br /> flag and stop any further updates on filesystem. So, it is safe to not<br /> set SB_RDONLY flag, let&amp;#39;s remove the logic and keep in line w/ ext4 [3].<br /> <br /> [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner<br /> [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3<br /> [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz