Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> 9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl<br /> <br /> We need to release directory fid if we fail halfway through open<br /> <br /> This fixes fid leaking with xfstests generic 531

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zonefs: fix zonefs_iomap_begin() for reads<br /> <br /> If a readahead is issued to a sequential zone file with an offset<br /> exactly equal to the current file size, the iomap type is set to<br /> IOMAP_UNWRITTEN, which will prevent an IO, but the iomap length is<br /> calculated as 0. This causes a WARN_ON() in iomap_iter():<br /> <br /> [17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80<br /> [...]<br /> [17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80<br /> [...]<br /> [17309.754560] Call Trace:<br /> [17309.757078] <br /> [17309.759240] ? lock_is_held_type+0xd8/0x130<br /> [17309.763531] iomap_readahead+0x1a8/0x870<br /> [17309.767550] ? iomap_read_folio+0x4c0/0x4c0<br /> [17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> [17309.778848] ? lock_release+0x370/0x750<br /> [17309.784462] ? folio_add_lru+0x217/0x3f0<br /> [17309.790220] ? reacquire_held_locks+0x4e0/0x4e0<br /> [17309.796543] read_pages+0x17d/0xb60<br /> [17309.801854] ? folio_add_lru+0x238/0x3f0<br /> [17309.807573] ? readahead_expand+0x5f0/0x5f0<br /> [17309.813554] ? policy_node+0xb5/0x140<br /> [17309.819018] page_cache_ra_unbounded+0x27d/0x450<br /> [17309.825439] filemap_get_pages+0x500/0x1450<br /> [17309.831444] ? filemap_add_folio+0x140/0x140<br /> [17309.837519] ? lock_is_held_type+0xd8/0x130<br /> [17309.843509] filemap_read+0x28c/0x9f0<br /> [17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs]<br /> [17309.856162] ? trace_contention_end+0xd6/0x130<br /> [17309.862416] ? __mutex_lock+0x221/0x1480<br /> [17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs]<br /> [17309.875364] ? filemap_get_pages+0x1450/0x1450<br /> [17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620<br /> [17309.888248] ? wait_for_completion_io_timeout+0x20/0x20<br /> [17309.895231] ? lock_is_held_type+0xd8/0x130<br /> [17309.901115] ? lock_is_held_type+0xd8/0x130<br /> [17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs]<br /> [17309.913750] new_sync_read+0x2d8/0x520<br /> [17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0<br /> <br /> Furthermore, this causes iomap_readahead() to loop forever as<br /> iomap_readahead_iter() always returns 0, making no progress.<br /> <br /> Fix this by treating reads after the file size as access to holes,<br /> setting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDR<br /> and using the length argument as is for the iomap length. To simplify<br /> the code with this change, zonefs_iomap_begin() is split into the read<br /> variant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and the<br /> write variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: add reserved GDT blocks check<br /> <br /> We capture a NULL pointer issue when resizing a corrupt ext4 image which<br /> is freshly clear resize_inode feature (not run e2fsck). It could be<br /> simply reproduced by following steps. The problem is because of the<br /> resize_inode feature was cleared, and it will convert the filesystem to<br /> meta_bg mode in ext4_resize_fs(), but the es-&gt;s_reserved_gdt_blocks was<br /> not reduced to zero, so could we mistakenly call reserve_backup_gdb()<br /> and passing an uninitialized resize_inode to it when adding new group<br /> descriptors.<br /> <br /> mkfs.ext4 /dev/sda 3G<br /> tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck<br /> mount /dev/sda /mnt<br /> resize2fs /dev/sda 8G<br /> <br /> ========<br /> BUG: kernel NULL pointer dereference, address: 0000000000000028<br /> CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748<br /> ...<br /> RIP: 0010:ext4_flex_group_add+0xe08/0x2570<br /> ...<br /> Call Trace:<br /> <br /> ext4_resize_fs+0xbec/0x1660<br /> __ext4_ioctl+0x1749/0x24e0<br /> ext4_ioctl+0x12/0x20<br /> __x64_sys_ioctl+0xa6/0x110<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f2dd739617b<br /> ========<br /> <br /> The fix is simple, add a check in ext4_resize_begin() to make sure that<br /> the es-&gt;s_reserved_gdt_blocks is zero when the resize_inode feature is<br /> disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on ext4_mb_use_inode_pa<br /> <br /> Hulk Robot reported a BUG_ON:<br /> ==================================================================<br /> kernel BUG at fs/ext4/mballoc.c:3211!<br /> [...]<br /> RIP: 0010:ext4_mb_mark_diskspace_used.cold+0x85/0x136f<br /> [...]<br /> Call Trace:<br /> ext4_mb_new_blocks+0x9df/0x5d30<br /> ext4_ext_map_blocks+0x1803/0x4d80<br /> ext4_map_blocks+0x3a4/0x1a10<br /> ext4_writepages+0x126d/0x2c30<br /> do_writepages+0x7f/0x1b0<br /> __filemap_fdatawrite_range+0x285/0x3b0<br /> file_write_and_wait_range+0xb1/0x140<br /> ext4_sync_file+0x1aa/0xca0<br /> vfs_fsync_range+0xfb/0x260<br /> do_fsync+0x48/0xa0<br /> [...]<br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> -------------------------------------<br /> do_fsync<br /> vfs_fsync_range<br /> ext4_sync_file<br /> file_write_and_wait_range<br /> __filemap_fdatawrite_range<br /> do_writepages<br /> ext4_writepages<br /> mpage_map_and_submit_extent<br /> mpage_map_one_extent<br /> ext4_map_blocks<br /> ext4_mb_new_blocks<br /> ext4_mb_normalize_request<br /> &gt;&gt;&gt; start + size ac_o_ex.fe_logical<br /> ext4_mb_regular_allocator<br /> ext4_mb_simple_scan_group<br /> ext4_mb_use_best_found<br /> ext4_mb_new_preallocation<br /> ext4_mb_new_inode_pa<br /> ext4_mb_use_inode_pa<br /> &gt;&gt;&gt; set ac-&gt;ac_b_ex.fe_len &gt;&gt; BUG_ON(ac-&gt;ac_b_ex.fe_len

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cfi: Fix __cfi_slowpath_diag RCU usage with cpuidle<br /> <br /> RCU_NONIDLE usage during __cfi_slowpath_diag can result in an invalid<br /> RCU state in the cpuidle code path:<br /> <br /> WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138<br /> ...<br /> Call trace:<br /> rcu_eqs_enter+0xe4/0x138<br /> rcu_idle_enter+0xa8/0x100<br /> cpuidle_enter_state+0x154/0x3a8<br /> cpuidle_enter+0x3c/0x58<br /> do_idle.llvm.6590768638138871020+0x1f4/0x2ec<br /> cpu_startup_entry+0x28/0x2c<br /> secondary_start_kernel+0x1b8/0x220<br /> __secondary_switched+0x94/0x98<br /> <br /> Instead, call rcu_irq_enter/exit to wake up RCU only when needed and<br /> disable interrupts for the entire CFI shadow/module check when we do.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm mirror log: round up region bitmap size to BITS_PER_LONG<br /> <br /> The code in dm-log rounds up bitset_size to 32 bits. It then uses<br /> find_next_zero_bit_le on the allocated region. find_next_zero_bit_le<br /> accesses the bitmap using unsigned long pointers. So, on 64-bit<br /> architectures, it may access 4 bytes beyond the allocated size.<br /> <br /> Fix this bug by rounding up bitset_size to BITS_PER_LONG.<br /> <br /> This bug was found by running the lvm2 testsuite with kasan.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: lpc32xx_udc: Fix refcount leak in lpc32xx_udc_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() will check NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc-bus: fix KASAN use-after-free in fsl_mc_bus_remove()<br /> <br /> In fsl_mc_bus_remove(), mc-&gt;root_mc_bus_dev-&gt;mc_io is passed to<br /> fsl_destroy_mc_io(). However, mc-&gt;root_mc_bus_dev is already freed in<br /> fsl_mc_device_remove(). Then reference to mc-&gt;root_mc_bus_dev-&gt;mc_io<br /> triggers KASAN use-after-free. To avoid the use-after-free, keep the<br /> reference to mc-&gt;root_mc_bus_dev-&gt;mc_io in a local variable and pass to<br /> fsl_destroy_mc_io().<br /> <br /> This patch needs rework to apply to kernels older than v5.15.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix hang during unmount when block group reclaim task is running<br /> <br /> When we start an unmount, at close_ctree(), if we have the reclaim task<br /> running and in the middle of a data block group relocation, we can trigger<br /> a deadlock when stopping an async reclaim task, producing a trace like the<br /> following:<br /> <br /> [629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000<br /> [629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]<br /> [629724.501267] Call Trace:<br /> [629724.501759] <br /> [629724.502174] __schedule+0x3cb/0xed0<br /> [629724.502842] schedule+0x4e/0xb0<br /> [629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs]<br /> [629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0<br /> [629724.505442] flush_space+0x423/0x630 [btrfs]<br /> [629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50<br /> [629724.507259] ? lock_release+0x220/0x4a0<br /> [629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs]<br /> [629724.508940] ? do_raw_spin_unlock+0x4b/0xa0<br /> [629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs]<br /> [629724.510922] process_one_work+0x252/0x5a0<br /> [629724.511694] ? process_one_work+0x5a0/0x5a0<br /> [629724.512508] worker_thread+0x52/0x3b0<br /> [629724.513220] ? process_one_work+0x5a0/0x5a0<br /> [629724.514021] kthread+0xf2/0x120<br /> [629724.514627] ? kthread_complete_and_exit+0x20/0x20<br /> [629724.515526] ret_from_fork+0x22/0x30<br /> [629724.516236] <br /> [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000<br /> [629724.518269] Call Trace:<br /> [629724.518746] <br /> [629724.519160] __schedule+0x3cb/0xed0<br /> [629724.519835] schedule+0x4e/0xb0<br /> [629724.520467] schedule_timeout+0xed/0x130<br /> [629724.521221] ? lock_release+0x220/0x4a0<br /> [629724.521946] ? lock_acquired+0x19c/0x420<br /> [629724.522662] ? trace_hardirqs_on+0x1b/0xe0<br /> [629724.523411] __wait_for_common+0xaf/0x1f0<br /> [629724.524189] ? usleep_range_state+0xb0/0xb0<br /> [629724.524997] __flush_work+0x26d/0x530<br /> [629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140<br /> [629724.526580] ? lock_acquire+0x1a0/0x310<br /> [629724.527324] __cancel_work_timer+0x137/0x1c0<br /> [629724.528190] close_ctree+0xfd/0x531 [btrfs]<br /> [629724.529000] ? evict_inodes+0x166/0x1c0<br /> [629724.529510] generic_shutdown_super+0x74/0x120<br /> [629724.530103] kill_anon_super+0x14/0x30<br /> [629724.530611] btrfs_kill_super+0x12/0x20 [btrfs]<br /> [629724.531246] deactivate_locked_super+0x31/0xa0<br /> [629724.531817] cleanup_mnt+0x147/0x1c0<br /> [629724.532319] task_work_run+0x5c/0xa0<br /> [629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0<br /> [629724.533598] syscall_exit_to_user_mode+0x16/0x40<br /> [629724.534200] do_syscall_64+0x48/0x90<br /> [629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [629724.535318] RIP: 0033:0x7fa2b90437a7<br /> [629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6<br /> [629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7<br /> [629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0<br /> [629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200<br /> [629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> [629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000<br /> [629724.541796] <br /> <br /> This happens because:<br /> <br /> 1) Before entering close_ctree() we have the async block group reclaim<br /> task running and relocating a data block group;<br /> <br /> 2) There&amp;#39;s an async metadata (or data) space reclaim task running;<br /> <br /> 3) We enter close_ctree() and park the cleaner kthread;<br /> <br /> 4) The async space reclaim task is at flush_space() and runs all the<br /> existing delayed iputs;<br /> <br /> 5) Before the async space reclaim task calls<br /> btrfs_wait_on_delayed_iputs(), the block group reclaim task which is<br /> doing the data block group relocation, creates a delayed iput at<br /> replace_file_extents() (called when COWing leaves that have file extent<br /> items pointing to relocated data exten<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ibmvfc: Store vhost pointer during subcrq allocation<br /> <br /> Currently the back pointer from a queue to the vhost adapter isn&amp;#39;t set<br /> until after subcrq interrupt registration. The value is available when a<br /> queue is first allocated and can/should be also set for primary and async<br /> queues as well as subcrqs.<br /> <br /> This fixes a crash observed during kexec/kdump on Power 9 with legacy XICS<br /> interrupt controller where a pending subcrq interrupt from the previous<br /> kernel can be replayed immediately upon IRQ registration resulting in<br /> dereference of a garbage backpointer in ibmvfc_interrupt_scsi().<br /> <br /> Kernel attempted to read user page (58) - exploit attempt? (uid: 0)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000058<br /> Faulting instruction address: 0xc008000003216a08<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> ...<br /> NIP [c008000003216a08] ibmvfc_interrupt_scsi+0x40/0xb0 [ibmvfc]<br /> LR [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270<br /> Call Trace:<br /> [c000000047fa3d80] [c0000000123e6180] 0xc0000000123e6180 (unreliable)<br /> [c000000047fa3df0] [c0000000082079e8] __handle_irq_event_percpu+0x98/0x270<br /> [c000000047fa3ea0] [c000000008207d18] handle_irq_event+0x98/0x188<br /> [c000000047fa3ef0] [c00000000820f564] handle_fasteoi_irq+0xc4/0x310<br /> [c000000047fa3f40] [c000000008205c60] generic_handle_irq+0x50/0x80<br /> [c000000047fa3f60] [c000000008015c40] __do_irq+0x70/0x1a0<br /> [c000000047fa3f90] [c000000008016d7c] __do_IRQ+0x9c/0x130<br /> [c000000014622f60] [0000000020000000] 0x20000000<br /> [c000000014622ff0] [c000000008016e50] do_IRQ+0x40/0xa0<br /> [c000000014623020] [c000000008017044] replay_soft_interrupts+0x194/0x2f0<br /> [c000000014623210] [c0000000080172a8] arch_local_irq_restore+0x108/0x170<br /> [c000000014623240] [c000000008eb1008] _raw_spin_unlock_irqrestore+0x58/0xb0<br /> [c000000014623270] [c00000000820b12c] __setup_irq+0x49c/0x9f0<br /> [c000000014623310] [c00000000820b7c0] request_threaded_irq+0x140/0x230<br /> [c000000014623380] [c008000003212a50] ibmvfc_register_scsi_channel+0x1e8/0x2f0 [ibmvfc]<br /> [c000000014623450] [c008000003213d1c] ibmvfc_init_sub_crqs+0xc4/0x1f0 [ibmvfc]<br /> [c0000000146234d0] [c0080000032145a8] ibmvfc_reset_crq+0x150/0x210 [ibmvfc]<br /> [c000000014623550] [c0080000032147c8] ibmvfc_init_crq+0x160/0x280 [ibmvfc]<br /> [c0000000146235f0] [c00800000321a9cc] ibmvfc_probe+0x2a4/0x530 [ibmvfc]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp4: Fix refcount leak in mdp4_modeset_init_intf<br /> <br /> of_graph_get_remote_node() returns remote device node pointer with<br /> refcount incremented, we should use of_node_put() on it<br /> when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/488473/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: disable the elevator int del_gendisk<br /> <br /> The elevator is only used for file system requests, which are stopped in<br /> del_gendisk. Move disabling the elevator and freeing the scheduler tags<br /> to the end of del_gendisk instead of doing that work in disk_release and<br /> blk_cleanup_queue to avoid a use after free on q-&gt;tag_set from<br /> disk_release as the tag_set might not be alive at that point.<br /> <br /> Move the blk_qos_exit call as well, as it just depends on the elevator<br /> exit and would be the only reason to keep the not exactly cheap queue<br /> freeze in disk_release.