Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114<br /> print_report+0xe8/0x550 mm/kasan/report.c:491<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> kasan_check_range+0x282/0x290 mm/kasan/generic.c:189<br /> instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]<br /> __refcount_add include/linux/refcount.h:184 [inline]<br /> __refcount_inc include/linux/refcount.h:241 [inline]<br /> refcount_inc include/linux/refcount.h:258 [inline]<br /> get_task_struct include/linux/sched/task.h:118 [inline]<br /> kthread_stop+0xca/0x630 kernel/kthread.c:704<br /> f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210<br /> f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283<br /> f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]<br /> __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:907 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893<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 /> <br /> The root cause is below race condition, it may cause use-after-free<br /> issue in sbi-&gt;gc_th pointer.<br /> <br /> - remount<br /> - f2fs_remount<br /> - f2fs_stop_gc_thread<br /> - kfree(gc_th)<br /> - f2fs_ioc_shutdown<br /> - f2fs_do_shutdown<br /> - f2fs_stop_gc_thread<br /> - kthread_stop(gc_th-&gt;f2fs_gc_task)<br /> : sbi-&gt;gc_thread = NULL;<br /> <br /> We will call f2fs_do_shutdown() in two paths:<br /> - for f2fs_ioc_shutdown() path, we should grab sb-&gt;s_umount semaphore<br /> for fixing.<br /> - for f2fs_shutdown() path, it&amp;#39;s safe since caller has already grabbed<br /> sb-&gt;s_umount semaphore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Skip Recompute DSC Params if no Stream on Link<br /> <br /> [why]<br /> Encounter NULL pointer dereference uner mst + dsc setup.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2<br /> Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022<br /> RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]<br /> Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 8&gt;<br /> RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224<br /> RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280<br /> RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850<br /> R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000<br /> R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224<br /> FS: 00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x171/0x4e0<br /> ? plist_add+0xbe/0x100<br /> ? exc_page_fault+0x7c/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]<br /> ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]<br /> compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]<br /> drm_atomic_check_only+0x5c5/0xa40<br /> drm_mode_atomic_ioctl+0x76e/0xbc0<br /> <br /> [how]<br /> dsc recompute should be skipped if no mode change detected on the new<br /> request. If detected, keep checking whether the stream is already on<br /> current state or not.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: sd: Fix off-by-one error in sd_read_block_characteristics()<br /> <br /> Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for<br /> example), sd_read_block_characteristics() may attempt an out-of-bounds<br /> memory access when accessing the zoned field at offset 8.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: check skb is non-NULL in tcp_rto_delta_us()<br /> <br /> We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic<br /> kernel that are running ceph and recently hit a null ptr dereference in<br /> tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also<br /> saw it getting hit from the RACK case as well. Here are examples of the oops<br /> messages we saw in each of those cases:<br /> <br /> Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode<br /> Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page<br /> Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0<br /> Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI<br /> Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu<br /> Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023<br /> Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160<br /> Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3<br /> Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246<br /> Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000<br /> Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60<br /> Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8<br /> Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900<br /> Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30<br /> Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000<br /> Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0<br /> Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554<br /> Jul 26 15:05:02 rx [11061395.916786] Call Trace:<br /> Jul 26 15:05:02 rx [11061395.919488]<br /> Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f<br /> Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9<br /> Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380<br /> Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0<br /> Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50<br /> Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0<br /> Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20<br /> Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450<br /> Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140<br /> Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90<br /> Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0<br /> Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40<br /> Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160<br /> Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160<br /> Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220<br /> Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240<br /> Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0<br /> Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240<br /> Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130<br /> Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280<br /> Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10<br /> Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30<br /> Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()<br /> <br /> The psc-&gt;div[] array has psc-&gt;num_div elements. These values come from<br /> when we call clk_hw_register_div(). It&amp;#39;s adc_divisors and<br /> ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be &gt;=<br /> instead of &gt; to prevent an out of bounds read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: get rid of online repaire on corrupted directory<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> kernel BUG at fs/f2fs/inode.c:896!<br /> RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896<br /> Call Trace:<br /> evict+0x532/0x950 fs/inode.c:704<br /> dispose_list fs/inode.c:747 [inline]<br /> evict_inodes+0x5f9/0x690 fs/inode.c:797<br /> generic_shutdown_super+0x9d/0x2d0 fs/super.c:627<br /> kill_block_super+0x44/0x90 fs/super.c:1696<br /> kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898<br /> deactivate_locked_super+0xc4/0x130 fs/super.c:473<br /> cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373<br /> task_work_run+0x24f/0x310 kernel/task_work.c:228<br /> ptrace_notify+0x2d2/0x380 kernel/signal.c:2402<br /> ptrace_report_syscall include/linux/ptrace.h:415 [inline]<br /> ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]<br /> syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173<br /> syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]<br /> syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218<br /> do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896<br /> <br /> Online repaire on corrupted directory in f2fs_lookup() can generate<br /> dirty data/meta while racing w/ readonly remount, it may leave dirty<br /> inode after filesystem becomes readonly, however, checkpoint() will<br /> skips flushing dirty inode in a state of readonly mode, result in<br /> above panic.<br /> <br /> Let&amp;#39;s get rid of online repaire in f2fs_lookup(), and leave the work<br /> to fsck.f2fs.