Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix wrong reg type conversion in release_reference()<br /> <br /> Some helper functions will allocate memory. To avoid memory leaks, the<br /> verifier requires the eBPF program to release these memories by calling<br /> the corresponding helper functions.<br /> <br /> When a resource is released, all pointer registers corresponding to the<br /> resource should be invalidated. The verifier use release_references() to<br /> do this job, by apply __mark_reg_unknown() to each relevant register.<br /> <br /> It will give these registers the type of SCALAR_VALUE. A register that<br /> will contain a pointer value at runtime, but of type SCALAR_VALUE, which<br /> may allow the unprivileged user to get a kernel pointer by storing this<br /> register into a map.<br /> <br /> Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hyperv: fix possible memory leak in mousevsc_probe()<br /> <br /> If hid_add_device() returns error, it should call hid_destroy_device()<br /> to free hid_dev which is allocated in hid_allocate_device().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE<br /> <br /> When using bpftool to pin {PROG, MAP, LINK} without FILE,<br /> segmentation fault will occur. The reson is that the lack<br /> of FILE will cause strlen to trigger NULL pointer dereference.<br /> The corresponding stacktrace is shown below:<br /> <br /> do_pin<br /> do_pin_any<br /> do_pin_fd<br /> mount_bpffs_for_pin<br /> strlen(name)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: fix general-protection-fault in ieee80211_subif_start_xmit()<br /> <br /> When device is running and the interface status is changed, the gpf issue<br /> is triggered. The problem triggering process is as follows:<br /> Thread A: Thread B<br /> ieee80211_runtime_change_iftype() process_one_work()<br /> ... ...<br /> ieee80211_do_stop() ...<br /> ... ...<br /> sdata-&gt;bss = NULL ...<br /> ... ieee80211_subif_start_xmit()<br /> ieee80211_multicast_to_unicast<br /> //!sdata-&gt;bss-&gt;multicast_to_unicast<br /> cause gpf issue<br /> <br /> When the interface status is changed, the sending queue continues to send<br /> packets. After the bss is set to NULL, the bss is accessed. As a result,<br /> this causes a general-protection-fault issue.<br /> <br /> The following is the stack information:<br /> general protection fault, probably for non-canonical address<br /> 0xdffffc000000002f: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000178-0x000000000000017f]<br /> Workqueue: mld mld_ifc_work<br /> RIP: 0010:ieee80211_subif_start_xmit+0x25b/0x1310<br /> Call Trace:<br /> <br /> dev_hard_start_xmit+0x1be/0x990<br /> __dev_queue_xmit+0x2c9a/0x3b60<br /> ip6_finish_output2+0xf92/0x1520<br /> ip6_finish_output+0x6af/0x11e0<br /> ip6_output+0x1ed/0x540<br /> mld_sendpack+0xa09/0xe70<br /> mld_ifc_work+0x71c/0xdb0<br /> process_one_work+0x9bf/0x1710<br /> worker_thread+0x665/0x1080<br /> kthread+0x2e4/0x3a0<br /> ret_from_fork+0x1f/0x30<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, verifier: Fix memory leak in array reallocation for stack state<br /> <br /> If an error (NULL) is returned by krealloc(), callers of realloc_array()<br /> were setting their allocation pointers to NULL, but on error krealloc()<br /> does not touch the original allocation. This would result in a memory<br /> resource leak. Instead, free the old allocation on the error handling<br /> path.<br /> <br /> The memory leak information is as follows as also reported by Zhengchao:<br /> <br /> unreferenced object 0xffff888019801800 (size 256):<br /> comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x45/0xc0<br /> [] krealloc+0x83/0xd0<br /> [] realloc_array+0x82/0xe2<br /> [] grow_stack_state+0xfb/0x186<br /> [] check_mem_access.cold+0x141/0x1341<br /> [] do_check_common+0x5358/0xb350<br /> [] bpf_check.cold+0xc3/0x29d<br /> [] bpf_prog_load+0x13db/0x2240<br /> [] __sys_bpf+0x1605/0x4ce0<br /> [] __x64_sys_bpf+0x75/0xb0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix warning in &amp;#39;ext4_da_release_space&amp;#39;<br /> <br /> Syzkaller report issue as follows:<br /> EXT4-fs (loop0): Free/Dirty block details<br /> EXT4-fs (loop0): free_blocks=0<br /> EXT4-fs (loop0): dirty_blocks=0<br /> EXT4-fs (loop0): Block reservation details<br /> EXT4-fs (loop0): i_reserved_data_blocks=0<br /> EXT4-fs warning (device loop0): ext4_da_release_space:1527: ext4_da_release_space: ino 18, to_free 1 with only 0 reserved data blocks<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1524<br /> Modules linked in:<br /> CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022<br /> Workqueue: writeback wb_workfn (flush-7:0)<br /> RIP: 0010:ext4_da_release_space+0x25e/0x370 fs/ext4/inode.c:1528<br /> RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296<br /> RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00<br /> RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000<br /> RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5<br /> R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000<br /> R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740<br /> FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ext4_es_remove_extent+0x1ab/0x260 fs/ext4/extents_status.c:1461<br /> mpage_release_unused_pages+0x24d/0xef0 fs/ext4/inode.c:1589<br /> ext4_writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852<br /> do_writepages+0x3c3/0x680 mm/page-writeback.c:2469<br /> __writeback_single_inode+0xd1/0x670 fs/fs-writeback.c:1587<br /> writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1870<br /> wb_writeback+0x41f/0x7b0 fs/fs-writeback.c:2044<br /> wb_do_writeback fs/fs-writeback.c:2187 [inline]<br /> wb_workfn+0x3cb/0xef0 fs/fs-writeback.c:2227<br /> process_one_work+0x877/0xdb0 kernel/workqueue.c:2289<br /> worker_thread+0xb14/0x1330 kernel/workqueue.c:2436<br /> kthread+0x266/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> <br /> Above issue may happens as follows:<br /> ext4_da_write_begin<br /> ext4_create_inline_data<br /> ext4_clear_inode_flag(inode, EXT4_INODE_EXTENTS);<br /> ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA);<br /> __ext4_ioctl<br /> ext4_ext_migrate -&gt; will lead to eh-&gt;eh_entries not zero, and set extent flag<br /> ext4_da_write_begin<br /> ext4_da_convert_inline_data_to_extent<br /> ext4_da_write_inline_data_begin<br /> ext4_da_map_blocks<br /> ext4_insert_delayed_block<br /> if (!ext4_es_scan_clu(inode, &amp;ext4_es_is_delonly, lblk))<br /> if (!ext4_es_scan_clu(inode, &amp;ext4_es_is_mapped, lblk))<br /> ext4_clu_mapped(inode, EXT4_B2C(sbi, lblk)); -&gt; will return 1<br /> allocated = true;<br /> ext4_es_insert_delayed_block(inode, lblk, allocated);<br /> ext4_writepages<br /> mpage_map_and_submit_extent(handle, &amp;mpd, &amp;give_up_on_write); -&gt; return -ENOSPC<br /> mpage_release_unused_pages(&amp;mpd, give_up_on_write); -&gt; give_up_on_write == 1<br /> ext4_es_remove_extent<br /> ext4_da_release_space(inode, reserved);<br /> if (unlikely(to_free &gt; ei-&gt;i_reserved_data_blocks))<br /> -&gt; to_free == 1 but ei-&gt;i_reserved_data_blocks == 0<br /> -&gt; then trigger warning as above<br /> <br /> To solve above issue, forbid inode do migrate which has inline data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: gso: fix panic on frag_list with mixed head alloc types<br /> <br /> Since commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat when<br /> splitting gso_size mangled skb having linear-headed frag_list"), it is<br /> allowed to change gso_size of a GRO packet. However, that commit assumes<br /> that "checking the first list_skb member suffices; i.e if either of the<br /> list_skb members have non head_frag head, then the first one has too".<br /> <br /> It turns out this assumption does not hold. We&amp;#39;ve seen BUG_ON being hit<br /> in skb_segment when skbs on the frag_list had differing head_frag with<br /> the vmxnet3 driver. This happens because __netdev_alloc_skb and<br /> __napi_alloc_skb can return a skb that is page backed or kmalloced<br /> depending on the requested size. As the result, the last small skb in<br /> the GRO packet can be kmalloced.<br /> <br /> There are three different locations where this can be fixed:<br /> <br /> (1) We could check head_frag in GRO and not allow GROing skbs with<br /> different head_frag. However, that would lead to performance<br /> regression on normal forward paths with unmodified gso_size, where<br /> !head_frag in the last packet is not a problem.<br /> <br /> (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating<br /> that NETIF_F_SG is undesirable. That would need to eat a bit in<br /> sk_buff. Furthermore, that flag can be unset when all skbs on the<br /> frag_list are page backed. To retain good performance,<br /> bpf_skb_net_grow/shrink would have to walk the frag_list.<br /> <br /> (3) Walk the frag_list in skb_segment when determining whether<br /> NETIF_F_SG should be cleared. This of course slows things down.<br /> <br /> This patch implements (3). To limit the performance impact in<br /> skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set<br /> that have gso_size changed. Normal paths thus will not hit it.<br /> <br /> We could check only the last skb but since we need to walk the whole<br /> list anyway, let&amp;#39;s stay on the safe side.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Fix the sk-&gt;sk_forward_alloc warning of sk_stream_kill_queues<br /> <br /> When running `test_sockmap` selftests, the following warning appears:<br /> <br /> WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0<br /> Call Trace:<br /> <br /> inet_csk_destroy_sock+0x55/0x110<br /> tcp_rcv_state_process+0xd28/0x1380<br /> ? tcp_v4_do_rcv+0x77/0x2c0<br /> tcp_v4_do_rcv+0x77/0x2c0<br /> __release_sock+0x106/0x130<br /> __tcp_close+0x1a7/0x4e0<br /> tcp_close+0x20/0x70<br /> inet_release+0x3c/0x80<br /> __sock_release+0x3a/0xb0<br /> sock_close+0x14/0x20<br /> __fput+0xa3/0x260<br /> task_work_run+0x59/0xb0<br /> exit_to_user_mode_prepare+0x1b3/0x1c0<br /> syscall_exit_to_user_mode+0x19/0x50<br /> do_syscall_64+0x48/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged<br /> while msg has more_data"), where I used msg-&gt;sg.size to replace the tosend,<br /> causing breakage:<br /> <br /> if (msg-&gt;apply_bytes &amp;&amp; msg-&gt;apply_bytes apply_bytes;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix BUG_ON() when directory entry has invalid rec_len<br /> <br /> The rec_len field in the directory entry has to be a multiple of 4. A<br /> corrupted filesystem image can be used to hit a BUG() in<br /> ext4_rec_len_to_disk(), called from make_indexed_dir().<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/ext4/ext4.h:2413!<br /> ...<br /> RIP: 0010:make_indexed_dir+0x53f/0x5f0<br /> ...<br /> Call Trace:<br /> <br /> ? add_dirent_to_buf+0x1b2/0x200<br /> ext4_add_entry+0x36e/0x480<br /> ext4_add_nondir+0x2b/0xc0<br /> ext4_create+0x163/0x200<br /> path_openat+0x635/0xe90<br /> do_filp_open+0xb4/0x160<br /> ? __create_object.isra.0+0x1de/0x3b0<br /> ? _raw_spin_unlock+0x12/0x30<br /> do_sys_openat2+0x91/0x150<br /> __x64_sys_open+0x6c/0xa0<br /> do_syscall_64+0x3c/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The fix simply adds a call to ext4_check_dir_entry() to validate the<br /> directory entry, returning -EFSCORRUPTED if the entry is invalid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix the msg-&gt;req tlv len check in tipc_nl_compat_name_table_dump_header<br /> <br /> This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value<br /> in tipc_nl_compat_name_table_dump") where it should have type casted<br /> sizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative<br /> value.<br /> <br /> syzbot reported a call trace because of it:<br /> <br /> BUG: KMSAN: uninit-value in ...<br /> tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934<br /> __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238<br /> tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321<br /> tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324<br /> genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]<br /> genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]<br /> genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792<br /> netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501<br /> genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg net/socket.c:734 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: af_can: fix NULL pointer dereference in can_rx_register()<br /> <br /> It causes NULL pointer dereference when testing as following:<br /> (a) use syscall(__NR_socket, 0x10ul, 3ul, 0) to create netlink socket.<br /> (b) use syscall(__NR_sendmsg, ...) to create bond link device and vxcan<br /> link device, and bind vxcan device to bond device (can also use<br /> ifenslave command to bind vxcan device to bond device).<br /> (c) use syscall(__NR_socket, 0x1dul, 3ul, 1) to create CAN socket.<br /> (d) use syscall(__NR_bind, ...) to bind the bond device to CAN socket.<br /> <br /> The bond device invokes the can-raw protocol registration interface to<br /> receive CAN packets. However, ml_priv is not allocated to the dev,<br /> dev_rcv_lists is assigned to NULL in can_rx_register(). In this case,<br /> it will occur the NULL pointer dereference issue.<br /> <br /> The following is the stack information:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> PGD 122a4067 P4D 122a4067 PUD 1223c067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP<br /> RIP: 0010:can_rx_register+0x12d/0x1e0<br /> Call Trace:<br /> <br /> raw_enable_filters+0x8d/0x120<br /> raw_enable_allfilters+0x3b/0x130<br /> raw_bind+0x118/0x4f0<br /> __sys_bind+0x163/0x1a0<br /> __x64_sys_bind+0x1e/0x30<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix NULL pointer dereference in svm_migrate_to_ram()<br /> <br /> ./drivers/gpu/drm/amd/amdkfd/kfd_migrate.c:985:58-62: ERROR: p is NULL but dereferenced.