Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix task hung in ext4_xattr_delete_inode<br /> <br /> Syzbot reported a hung task problem:<br /> ==================================================================<br /> INFO: task syz-executor232:5073 blocked for more than 143 seconds.<br /> Not tainted 6.2.0-rc2-syzkaller-00024-g512dee0c00ad #0<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz-exec232 state:D stack:21024 pid:5073 ppid:5072 flags:0x00004004<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5244 [inline]<br /> __schedule+0x995/0xe20 kernel/sched/core.c:6555<br /> schedule+0xcb/0x190 kernel/sched/core.c:6631<br /> __wait_on_freeing_inode fs/inode.c:2196 [inline]<br /> find_inode_fast+0x35a/0x4c0 fs/inode.c:950<br /> iget_locked+0xb1/0x830 fs/inode.c:1273<br /> __ext4_iget+0x22e/0x3ed0 fs/ext4/inode.c:4861<br /> ext4_xattr_inode_iget+0x68/0x4e0 fs/ext4/xattr.c:389<br /> ext4_xattr_inode_dec_ref_all+0x1a7/0xe50 fs/ext4/xattr.c:1148<br /> ext4_xattr_delete_inode+0xb04/0xcd0 fs/ext4/xattr.c:2880<br /> ext4_evict_inode+0xd7c/0x10b0 fs/ext4/inode.c:296<br /> evict+0x2a4/0x620 fs/inode.c:664<br /> ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474<br /> __ext4_fill_super fs/ext4/super.c:5516 [inline]<br /> ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644<br /> get_tree_bdev+0x400/0x620 fs/super.c:1282<br /> vfs_get_tree+0x88/0x270 fs/super.c:1489<br /> do_new_mount+0x289/0xad0 fs/namespace.c:3145<br /> do_mount fs/namespace.c:3488 [inline]<br /> __do_sys_mount fs/namespace.c:3697 [inline]<br /> __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fa5406fd5ea<br /> RSP: 002b:00007ffc7232f968 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fa5406fd5ea<br /> RDX: 0000000020000440 RSI: 0000000020000000 RDI: 00007ffc7232f970<br /> RBP: 00007ffc7232f970 R08: 00007ffc7232f9b0 R09: 0000000000000432<br /> R10: 0000000000804a03 R11: 0000000000000202 R12: 0000000000000004<br /> R13: 0000555556a7a2c0 R14: 00007ffc7232f9b0 R15: 0000000000000000<br /> <br /> ==================================================================<br /> <br /> The problem is that the inode contains an xattr entry with ea_inum of 15<br /> when cleaning up an orphan inode . When evict inode , the reference<br /> counting of the corresponding EA inode is decreased. When EA inode is<br /> found by find_inode_fast() in __ext4_iget(), it is found that the EA inode<br /> holds the I_FREEING flag and waits for the EA inode to complete deletion.<br /> As a result, when inode is being deleted, we wait for inode to<br /> complete the deletion, resulting in an infinite loop and triggering Hung<br /> Task. To solve this problem, we only need to check whether the ino of EA<br /> inode and parent is the same before getting EA inode.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fix UaF in listener shutdown<br /> <br /> As reported by Christoph after having refactored the passive<br /> socket initialization, the mptcp listener shutdown path is prone<br /> to an UaF issue.<br /> <br /> BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x73/0xe0<br /> Write of size 4 at addr ffff88810cb23098 by task syz-executor731/1266<br /> <br /> CPU: 1 PID: 1266 Comm: syz-executor731 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6e/0x91<br /> print_report+0x16a/0x46f<br /> kasan_report+0xad/0x130<br /> kasan_check_range+0x14a/0x1a0<br /> _raw_spin_lock_bh+0x73/0xe0<br /> subflow_error_report+0x6d/0x110<br /> sk_error_report+0x3b/0x190<br /> tcp_disconnect+0x138c/0x1aa0<br /> inet_child_forget+0x6f/0x2e0<br /> inet_csk_listen_stop+0x209/0x1060<br /> __mptcp_close_ssk+0x52d/0x610<br /> mptcp_destroy_common+0x165/0x640<br /> mptcp_destroy+0x13/0x80<br /> __mptcp_destroy_sock+0xe7/0x270<br /> __mptcp_close+0x70e/0x9b0<br /> mptcp_close+0x2b/0x150<br /> inet_release+0xe9/0x1f0<br /> __sock_release+0xd2/0x280<br /> sock_close+0x15/0x20<br /> __fput+0x252/0xa20<br /> task_work_run+0x169/0x250<br /> exit_to_user_mode_prepare+0x113/0x120<br /> syscall_exit_to_user_mode+0x1d/0x40<br /> do_syscall_64+0x48/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> The msk grace period can legitly expire in between the last<br /> reference count dropped in mptcp_subflow_queue_clean() and<br /> the later eventual access in inet_csk_listen_stop()<br /> <br /> After the previous patch we don&amp;#39;t need anymore special-casing<br /> msk listener socket cleanup: the mptcp worker will process each<br /> of the unaccepted msk sockets.<br /> <br /> Just drop the now unnecessary code.<br /> <br /> Please note this commit depends on the two parent ones:<br /> <br /> mptcp: refactor passive socket initialization<br /> mptcp: use the workqueue to destroy unaccepted sockets

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/active: Fix misuse of non-idle barriers as fence trackers<br /> <br /> Users reported oopses on list corruptions when using i915 perf with a<br /> number of concurrently running graphics applications. Root cause analysis<br /> pointed at an issue in barrier processing code -- a race among perf open /<br /> close replacing active barriers with perf requests on kernel context and<br /> concurrent barrier preallocate / acquire operations performed during user<br /> context first pin / last unpin.<br /> <br /> When adding a request to a composite tracker, we try to reuse an existing<br /> fence tracker, already allocated and registered with that composite. The<br /> tracker we obtain may already track another fence, may be an idle barrier,<br /> or an active barrier.<br /> <br /> If the tracker we get occurs a non-idle barrier then we try to delete that<br /> barrier from a list of barrier tasks it belongs to. However, while doing<br /> that we don&amp;#39;t respect return value from a function that performs the<br /> barrier deletion. Should the deletion ever fail, we would end up reusing<br /> the tracker still registered as a barrier task. Since the same structure<br /> field is reused with both fence callback lists and barrier tasks list,<br /> list corruptions would likely occur.<br /> <br /> Barriers are now deleted from a barrier tasks list by temporarily removing<br /> the list content, traversing that content with skip over the node to be<br /> deleted, then populating the list back with the modified content. Should<br /> that intentionally racy concurrent deletion attempts be not serialized,<br /> one or more of those may fail because of the list being temporary empty.<br /> <br /> Related code that ignores the results of barrier deletion was initially<br /> introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the<br /> idle-barrier from other kernel requests"). However, all users of the<br /> barrier deletion routine were apparently serialized at that time, then the<br /> issue didn&amp;#39;t exhibit itself. Results of git bisect with help of a newly<br /> developed igt@gem_barrier_race@remote-request IGT test indicate that list<br /> corruptions might start to appear after commit 311770173fac ("drm/i915/gt:<br /> Schedule request retirement when timeline idles"), introduced in v5.5.<br /> <br /> Respect results of barrier deletion attempts -- mark the barrier as idle<br /> only if successfully deleted from the list. Then, before proceeding with<br /> setting our fence as the one currently tracked, make sure that the tracker<br /> we&amp;#39;ve got is not a non-idle barrier. If that check fails then don&amp;#39;t use<br /> that tracker but go back and try to acquire a new, usable one.<br /> <br /> v3: use unlikely() to document what outcome we expect (Andi),<br /> - fix bad grammar in commit description.<br /> v2: no code changes,<br /> - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement<br /> when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow<br /> sharing the idle-barrier from other kernel requests"), v5.4,<br /> - reword commit description.<br /> <br /> (cherry picked from commit 506006055769b10d1b2b4e22f636f3b45e0e9fc7)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: connac: do not check WED status for non-mmio devices<br /> <br /> WED is supported just for mmio devices, so do not check it for usb or<br /> sdio devices. This patch fixes the crash reported below:<br /> <br /> [ 21.946627] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d<br /> [ 22.525298] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)<br /> [ 22.548274] wlp0s3u1i3: authenticate with c4:41:1e:f5:2b:1d<br /> [ 22.557694] wlp0s3u1i3: send auth to c4:41:1e:f5:2b:1d (try 1/3)<br /> [ 22.565885] wlp0s3u1i3: authenticated<br /> [ 22.569502] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 1/3)<br /> [ 22.578966] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=30 aid=3)<br /> [ 22.579113] wlp0s3u1i3: c4:41:1e:f5:2b:1d rejected association temporarily; comeback duration 1000 TU (1024 ms)<br /> [ 23.649518] wlp0s3u1i3: associate with c4:41:1e:f5:2b:1d (try 2/3)<br /> [ 23.752528] wlp0s3u1i3: RX AssocResp from c4:41:1e:f5:2b:1d (capab=0x11 status=0 aid=3)<br /> [ 23.797450] wlp0s3u1i3: associated<br /> [ 24.959527] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)<br /> [ 24.959640] BUG: unable to handle page fault for address: ffff88800c223200<br /> [ 24.959706] #PF: supervisor instruction fetch in kernel mode<br /> [ 24.959788] #PF: error_code(0x0011) - permissions violation<br /> [ 24.959846] PGD 2c01067 P4D 2c01067 PUD 2c02067 PMD c2a8063 PTE 800000000c223163<br /> [ 24.959957] Oops: 0011 [#1] PREEMPT SMP<br /> [ 24.960009] CPU: 0 PID: 391 Comm: wpa_supplicant Not tainted 6.2.0-kvm #18<br /> [ 24.960089] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014<br /> [ 24.960191] RIP: 0010:0xffff88800c223200<br /> [ 24.960446] RSP: 0018:ffffc90000ff7698 EFLAGS: 00010282<br /> [ 24.960513] RAX: ffff888028397010 RBX: ffff88800c26e630 RCX: 0000000000000058<br /> [ 24.960598] RDX: ffff88800c26f844 RSI: 0000000000000006 RDI: ffff888028397010<br /> [ 24.960682] RBP: ffff88800ea72f00 R08: 18b873fbab2b964c R09: be06b38235f3c63c<br /> [ 24.960766] R10: 18b873fbab2b964c R11: be06b38235f3c63c R12: 0000000000000001<br /> [ 24.960853] R13: ffff88800c26f84c R14: ffff8880063f0ff8 R15: ffff88800c26e644<br /> [ 24.960950] FS: 00007effcea327c0(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000<br /> [ 24.961036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 24.961106] CR2: ffff88800c223200 CR3: 000000000eaa2000 CR4: 00000000000006b0<br /> [ 24.961190] Call Trace:<br /> [ 24.961219] <br /> [ 24.961245] ? mt76_connac_mcu_add_key+0x2cf/0x310<br /> [ 24.961313] ? mt7921_set_key+0x150/0x200<br /> [ 24.961365] ? drv_set_key+0xa9/0x1b0<br /> [ 24.961418] ? ieee80211_key_enable_hw_accel+0xd9/0x240<br /> [ 24.961485] ? ieee80211_key_replace+0x3f3/0x730<br /> [ 24.961541] ? crypto_shash_setkey+0x89/0xd0<br /> [ 24.961597] ? ieee80211_key_link+0x2d7/0x3a0<br /> [ 24.961664] ? crypto_aead_setauthsize+0x31/0x50<br /> [ 24.961730] ? sta_info_hash_lookup+0xa6/0xf0<br /> [ 24.961785] ? ieee80211_add_key+0x1fc/0x250<br /> [ 24.961842] ? rdev_add_key+0x41/0x140<br /> [ 24.961882] ? nl80211_parse_key+0x6c/0x2f0<br /> [ 24.961940] ? nl80211_new_key+0x24a/0x290<br /> [ 24.961984] ? genl_rcv_msg+0x36c/0x3a0<br /> [ 24.962036] ? rdev_mod_link_station+0xe0/0xe0<br /> [ 24.962102] ? nl80211_set_key+0x410/0x410<br /> [ 24.962143] ? nl80211_pre_doit+0x200/0x200<br /> [ 24.962187] ? genl_bind+0xc0/0xc0<br /> [ 24.962217] ? netlink_rcv_skb+0xaa/0xd0<br /> [ 24.962259] ? genl_rcv+0x24/0x40<br /> [ 24.962300] ? netlink_unicast+0x224/0x2f0<br /> [ 24.962345] ? netlink_sendmsg+0x30b/0x3d0<br /> [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0<br /> [ 24.962388] ? ____sys_sendmsg+0x109/0x1b0<br /> [ 24.962440] ? __import_iovec+0x2e/0x110<br /> [ 24.962482] ? ___sys_sendmsg+0xbe/0xe0<br /> [ 24.962525] ? mod_objcg_state+0x25c/0x330<br /> [ 24.962576] ? __dentry_kill+0x19e/0x1d0<br /> [ 24.962618] ? call_rcu+0x18f/0x270<br /> [ 24.962660] ? __dentry_kill+0x19e/0x1d0<br /> [ 24.962702] ? __x64_sys_sendmsg+0x70/0x90<br /> [ 24.962744] ? do_syscall_64+0x3d/0x80<br /> [ 24.962796] ? exit_to_user_mode_prepare+0x1b/0x70<br /> [ 24.962852] ? entry_SYSCA<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/shmem-helper: Remove another errant put in error path<br /> <br /> drm_gem_shmem_mmap() doesn&amp;#39;t own reference in error code path, resulting<br /> in the dma-buf shmem GEM object getting prematurely freed leading to a<br /> later use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: don&amp;#39;t replace page in rq_pages if it&amp;#39;s a continuation of last page<br /> <br /> The splice read calls nfsd_splice_actor to put the pages containing file<br /> data into the svc_rqst-&gt;rq_pages array. It&amp;#39;s possible however to get a<br /> splice result that only has a partial page at the end, if (e.g.) the<br /> filesystem hands back a short read that doesn&amp;#39;t cover the whole page.<br /> <br /> nfsd_splice_actor will plop the partial page into its rq_pages array and<br /> return. Then later, when nfsd_splice_actor is called again, the<br /> remainder of the page may end up being filled out. At this point,<br /> nfsd_splice_actor will put the page into the array _again_ corrupting<br /> the reply. If this is done enough times, rq_next_page will overrun the<br /> array and corrupt the trailing fields -- the rq_respages and<br /> rq_next_page pointers themselves.<br /> <br /> If we&amp;#39;ve already added the page to the array in the last pass, don&amp;#39;t add<br /> it to the array a second time when dealing with a splice continuation.<br /> This was originally handled properly in nfsd_splice_actor, but commit<br /> 91e23b1c3982 ("NFSD: Clean up nfsd_splice_actor()") removed the check<br /> for it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/edid: fix info leak when failing to get panel id<br /> <br /> Make sure to clear the transfer buffer before fetching the EDID to<br /> avoid leaking slab data to the logs on errors that leave the buffer<br /> unchanged.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix steering rules cleanup<br /> <br /> vport&amp;#39;s mc, uc and multicast rules are not deleted in teardown path when<br /> EEH happens. Since the vport&amp;#39;s promisc settings(uc, mc and all) in<br /> firmware are reset after EEH, mlx5 driver will try to delete the above<br /> rules in the initialization path. This cause kernel crash because these<br /> software rules are no longer valid.<br /> <br /> Fix by nullifying these rules right after delete to avoid accessing any dangling<br /> pointers.<br /> <br /> Call Trace:<br /> __list_del_entry_valid+0xcc/0x100 (unreliable)<br /> tree_put_node+0xf4/0x1b0 [mlx5_core]<br /> tree_remove_node+0x30/0x70 [mlx5_core]<br /> mlx5_del_flow_rules+0x14c/0x1f0 [mlx5_core]<br /> esw_apply_vport_rx_mode+0x10c/0x200 [mlx5_core]<br /> esw_update_vport_rx_mode+0xb4/0x180 [mlx5_core]<br /> esw_vport_change_handle_locked+0x1ec/0x230 [mlx5_core]<br /> esw_enable_vport+0x130/0x260 [mlx5_core]<br /> mlx5_eswitch_enable_sriov+0x2a0/0x2f0 [mlx5_core]<br /> mlx5_device_enable_sriov+0x74/0x440 [mlx5_core]<br /> mlx5_load_one+0x114c/0x1550 [mlx5_core]<br /> mlx5_pci_resume+0x68/0xf0 [mlx5_core]<br /> eeh_report_resume+0x1a4/0x230<br /> eeh_pe_dev_traverse+0x98/0x170<br /> eeh_handle_normal_event+0x3e4/0x640<br /> eeh_handle_event+0x4c/0x370<br /> eeh_event_handler+0x14c/0x210<br /> kthread+0x168/0x1b0<br /> ret_from_kernel_thread+0x5c/0x84

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_dh_alua: Fix memleak for &amp;#39;qdata&amp;#39; in alua_activate()<br /> <br /> If alua_rtpg_queue() failed from alua_activate(), then &amp;#39;qdata&amp;#39; is not<br /> freed, which will cause following memleak:<br /> <br /> unreferenced object 0xffff88810b2c6980 (size 32):<br /> comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............<br /> backtrace:<br /> [] alua_activate+0xb0/0x320<br /> [] scsi_dh_activate+0xb2/0x140<br /> [] activate_path_work+0xc6/0xe0 [dm_multipath]<br /> [] process_one_work+0x3c5/0x730<br /> [] worker_thread+0x93/0x650<br /> [] kthread+0x1ba/0x210<br /> [] ret_from_fork+0x22/0x30<br /> <br /> Fix the problem by freeing &amp;#39;qdata&amp;#39; in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fix shift-out-of-bounds in CalculateVMAndRowBytes<br /> <br /> [WHY]<br /> When PTEBufferSizeInRequests is zero, UBSAN reports the following<br /> warning because dml_log2 returns an unexpected negative value:<br /> <br /> shift exponent 4294966273 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> [HOW]<br /> <br /> In the case PTEBufferSizeInRequests is zero, skip the dml_log2() and<br /> assign the result directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix invalid address access in lookup_rec() when index is 0<br /> <br /> KASAN reported follow problem:<br /> <br /> BUG: KASAN: use-after-free in lookup_rec<br /> Read of size 8 at addr ffff000199270ff0 by task modprobe<br /> CPU: 2 Comm: modprobe<br /> Call trace:<br /> kasan_report<br /> __asan_load8<br /> lookup_rec<br /> ftrace_location<br /> arch_check_ftrace_location<br /> check_kprobe_address_safe<br /> register_kprobe<br /> <br /> When checking pg-&gt;records[pg-&gt;index - 1].ip in lookup_rec(), it can get a<br /> pg which is newly added to ftrace_pages_start in ftrace_process_locs().<br /> Before the first pg-&gt;index++, index is 0 and accessing pg-&gt;records[-1].ip<br /> will cause this problem.<br /> <br /> Don&amp;#39;t check the ip when pg-&gt;index is 0.