Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_ets: don&amp;#39;t remove idle classes from the round-robin list<br /> <br /> Shuang reported that the following script:<br /> <br /> 1) tc qdisc add dev ddd0 handle 10: parent 1: ets bands 8 strict 4 priomap 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7<br /> 2) mausezahn ddd0 -A 10.10.10.1 -B 10.10.10.2 -c 0 -a own -b 00:c1:a0:c1:a0:00 -t udp &amp;<br /> 3) tc qdisc change dev ddd0 handle 10: ets bands 4 strict 2 quanta 2500 2500 priomap 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3<br /> <br /> crashes systematically when line 2) is commented:<br /> <br /> list_del corruption, ffff8e028404bd30-&gt;next is LIST_POISON1 (dead000000000100)<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:47!<br /> invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 0 PID: 954 Comm: tc Not tainted 5.16.0-rc4+ #478<br /> Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014<br /> RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47<br /> Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe<br /> RSP: 0018:ffffae46807a3888 EFLAGS: 00010246<br /> RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202<br /> RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff<br /> RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff<br /> R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800<br /> R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400<br /> FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000682f48 CR3: 00000001058be000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ets_qdisc_change+0x58b/0xa70 [sch_ets]<br /> tc_modify_qdisc+0x323/0x880<br /> rtnetlink_rcv_msg+0x169/0x4a0<br /> netlink_rcv_skb+0x50/0x100<br /> netlink_unicast+0x1a5/0x280<br /> netlink_sendmsg+0x257/0x4d0<br /> sock_sendmsg+0x5b/0x60<br /> ____sys_sendmsg+0x1f2/0x260<br /> ___sys_sendmsg+0x7c/0xc0<br /> __sys_sendmsg+0x57/0xa0<br /> do_syscall_64+0x3a/0x80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7efdc8031338<br /> Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 43 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55<br /> RSP: 002b:00007ffdf1ce9828 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000061b37a97 RCX: 00007efdc8031338<br /> RDX: 0000000000000000 RSI: 00007ffdf1ce9890 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 000000000078a940<br /> R10: 000000000000000c R11: 0000000000000246 R12: 0000000000000001<br /> R13: 0000000000688880 R14: 0000000000000000 R15: 0000000000000000<br /> <br /> Modules linked in: sch_ets sch_tbf dummy rfkill iTCO_wdt iTCO_vendor_support intel_rapl_msr intel_rapl_common joydev pcspkr i2c_i801 virtio_balloon i2c_smbus lpc_ich ip_tables xfs libcrc32c crct10dif_pclmul crc32_pclmul crc32c_intel serio_raw ghash_clmulni_intel ahci libahci libata virtio_blk virtio_console virtio_net net_failover failover sunrpc dm_mirror dm_region_hash dm_log dm_mod [last unloaded: sch_ets]<br /> ---[ end trace f35878d1912655c2 ]---<br /> RIP: 0010:__list_del_entry_valid.cold.1+0x12/0x47<br /> Code: fe ff 0f 0b 48 89 c1 4c 89 c6 48 c7 c7 08 42 1b 87 e8 1d c5 fe ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 98 42 1b 87 e8 09 c5 fe ff 0b 48 c7 c7 48 43 1b 87 e8 fb c4 fe ff 0f 0b 48 89 f2 48 89 fe<br /> RSP: 0018:ffffae46807a3888 EFLAGS: 00010246<br /> RAX: 000000000000004e RBX: 0000000000000007 RCX: 0000000000000202<br /> RDX: 0000000000000000 RSI: ffffffff871ac536 RDI: 00000000ffffffff<br /> RBP: ffffae46807a3a10 R08: 0000000000000000 R09: c0000000ffff7fff<br /> R10: 0000000000000001 R11: ffffae46807a36a8 R12: ffff8e028404b800<br /> R13: ffff8e028404bd30 R14: dead000000000100 R15: ffff8e02fafa2400<br /> FS: 00007efdc92e4480(0000) GS:ffff8e02fb600000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000000000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg<br /> <br /> Currently, the hns3_remove function firstly uninstall client instance,<br /> and then uninstall acceletion engine device. The netdevice is freed in<br /> client instance uninstall process, but acceletion engine device uninstall<br /> process still use it to trace runtime information. This causes a use after<br /> free problem.<br /> <br /> So fixes it by check the instance register state to avoid use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet_diag: fix kernel-infoleak for UDP sockets<br /> <br /> KMSAN reported a kernel-infoleak [1], that can exploited<br /> by unpriv users.<br /> <br /> After analysis it turned out UDP was not initializing<br /> r-&gt;idiag_expires. Other users of inet_sk_diag_fill()<br /> might make the same mistake in the future, so fix this<br /> in inet_sk_diag_fill().<br /> <br /> [1]<br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670<br /> instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> copyout lib/iov_iter.c:156 [inline]<br /> _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670<br /> copy_to_iter include/linux/uio.h:155 [inline]<br /> simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519<br /> __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425<br /> skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533<br /> skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]<br /> netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974<br /> sock_recvmsg_nosec net/socket.c:944 [inline]<br /> sock_recvmsg net/socket.c:962 [inline]<br /> sock_read_iter+0x5a9/0x630 net/socket.c:1035<br /> call_read_iter include/linux/fs.h:2156 [inline]<br /> new_sync_read fs/read_write.c:400 [inline]<br /> vfs_read+0x1631/0x1980 fs/read_write.c:481<br /> ksys_read+0x28c/0x520 fs/read_write.c:619<br /> __do_sys_read fs/read_write.c:629 [inline]<br /> __se_sys_read fs/read_write.c:627 [inline]<br /> __x64_sys_read+0xdb/0x120 fs/read_write.c:627<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:524 [inline]<br /> slab_alloc_node mm/slub.c:3251 [inline]<br /> __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974<br /> kmalloc_reserve net/core/skbuff.c:354 [inline]<br /> __alloc_skb+0x545/0xf90 net/core/skbuff.c:426<br /> alloc_skb include/linux/skbuff.h:1126 [inline]<br /> netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245<br /> __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370<br /> netlink_dump_start include/linux/netlink.h:254 [inline]<br /> inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343<br /> sock_diag_rcv_msg+0x24a/0x620<br /> netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491<br /> sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg net/socket.c:724 [inline]<br /> sock_write_iter+0x594/0x690 net/socket.c:1057<br /> do_iter_readv_writev+0xa7f/0xc70<br /> do_iter_write+0x52c/0x1500 fs/read_write.c:851<br /> vfs_writev fs/read_write.c:924 [inline]<br /> do_writev+0x63f/0xe30 fs/read_write.c:967<br /> __do_sys_writev fs/read_write.c:1040 [inline]<br /> __se_sys_writev fs/read_write.c:1037 [inline]<br /> __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Bytes 68-71 of 312 are uninitialized<br /> Memory access of size 312 starts at ffff88812ab54000<br /> Data copied to user address 0000000020001440<br /> <br /> CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sch_cake: do not call cake_destroy() from cake_init()<br /> <br /> qdiscs are not supposed to call their own destroy() method<br /> from init(), because core stack already does that.<br /> <br /> syzbot was able to trigger use after free:<br /> <br /> DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)<br /> WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]<br /> WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740<br /> Modules linked in:<br /> CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]<br /> RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740<br /> Code: 08 84 d2 0f 85 19 08 00 00 8b 05 97 38 4b 04 85 c0 0f 85 27 f7 ff ff 48 c7 c6 20 00 ac 89 48 c7 c7 a0 fe ab 89 e8 bf 76 ba ff 0b e9 0d f7 ff ff 48 8b 44 24 40 48 8d b8 c8 08 00 00 48 89 f8<br /> RSP: 0018:ffffc9000627f290 EFLAGS: 00010282<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000<br /> RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44<br /> RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000<br /> R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000<br /> FS: 0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810<br /> tcf_block_put_ext net/sched/cls_api.c:1381 [inline]<br /> tcf_block_put_ext net/sched/cls_api.c:1376 [inline]<br /> tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394<br /> cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695<br /> qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293<br /> tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660<br /> rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571<br /> netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]<br /> netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345<br /> netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921<br /> sock_sendmsg_nosec net/socket.c:704 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:724<br /> ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409<br /> ___sys_sendmsg+0xf3/0x170 net/socket.c:2463<br /> __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7f1bb06badb9<br /> Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.<br /> RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9<br /> RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003<br /> RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003<br /> R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688<br /> R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: use latest_dev in btrfs_show_devname<br /> <br /> The test case btrfs/238 reports the warning below:<br /> <br /> WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]<br /> CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015<br /> Call trace:<br /> btrfs_show_devname+0x108/0x1b4 [btrfs]<br /> show_mountinfo+0x234/0x2c4<br /> m_show+0x28/0x34<br /> seq_read_iter+0x12c/0x3c4<br /> vfs_read+0x29c/0x2c8<br /> ksys_read+0x80/0xec<br /> __arm64_sys_read+0x28/0x34<br /> invoke_syscall+0x50/0xf8<br /> do_el0_svc+0x88/0x138<br /> el0_svc+0x2c/0x8c<br /> el0t_64_sync_handler+0x84/0xe4<br /> el0t_64_sync+0x198/0x19c<br /> <br /> Reason:<br /> While btrfs_prepare_sprout() moves the fs_devices::devices into<br /> fs_devices::seed_list, the btrfs_show_devname() searches for the devices<br /> and found none, leading to the warning as in above.<br /> <br /> Fix:<br /> latest_dev is updated according to the changes to the device list.<br /> That means we could use the latest_dev-&gt;name to show the device name in<br /> /proc/self/mounts, the pointer will be always valid as it&amp;#39;s assigned<br /> before the device is deleted from the list in remove or replace.<br /> The RCU protection is sufficient as the device structure is freed after<br /> synchronization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm btree remove: fix use after free in rebalance_children()<br /> <br /> Move dm_tm_unlock() after dm_tm_dec().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: amdtee: fix an IS_ERR() vs NULL bug<br /> <br /> The __get_free_pages() function does not return error pointers it returns<br /> NULL so fix this condition to avoid a NULL dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: track only QoS data frames for admission control<br /> <br /> For admission control, obviously all of that only works for<br /> QoS data frames, otherwise we cannot even access the QoS<br /> field in the header.<br /> <br /> Syzbot reported (see below) an uninitialized value here due<br /> to a status of a non-QoS nullfunc packet, which isn&amp;#39;t even<br /> long enough to contain the QoS header.<br /> <br /> Fix this to only do anything for QoS data packets.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> audit: improve robustness of the audit queue handling<br /> <br /> If the audit daemon were ever to get stuck in a stopped state the<br /> kernel&amp;#39;s kauditd_thread() could get blocked attempting to send audit<br /> records to the userspace audit daemon. With the kernel thread<br /> blocked it is possible that the audit queue could grow unbounded as<br /> certain audit record generating events must be exempt from the queue<br /> limits else the system enter a deadlock state.<br /> <br /> This patch resolves this problem by lowering the kernel thread&amp;#39;s<br /> socket sending timeout from MAX_SCHEDULE_TIMEOUT to HZ/10 and tweaks<br /> the kauditd_send_queue() function to better manage the various audit<br /> queues when connection problems occur between the kernel and the<br /> audit daemon. With this patch, the backlog may temporarily grow<br /> beyond the defined limits when the audit daemon is stopped and the<br /> system is under heavy audit pressure, but kauditd_thread() will<br /> continue to make progress and drain the queues as it would for other<br /> connection problems. For example, with the audit daemon put into a<br /> stopped state and the system configured to audit every syscall it<br /> was still possible to shutdown the system without a kernel panic,<br /> deadlock, etc.; granted, the system was slow to shutdown but that is<br /> to be expected given the extreme pressure of recording every syscall.<br /> <br /> The timeout value of HZ/10 was chosen primarily through<br /> experimentation and this developer&amp;#39;s "gut feeling". There is likely<br /> no one perfect value, but as this scenario is limited in scope (root<br /> privileges would be needed to send SIGSTOP to the audit daemon), it<br /> is likely not worth exposing this as a tunable at present. This can<br /> always be done at a later date if it proves necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: check that offset is within bounds in get_config()<br /> <br /> This condition checks "len" but it does not check "offset" and that<br /> could result in an out of bounds read if "offset &gt; dev-&gt;config_size".<br /> The problem is that since both variables are unsigned the<br /> "dev-&gt;config_size - offset" subtraction would result in a very high<br /> unsigned value.<br /> <br /> I think these checks might not be necessary because "len" and "offset"<br /> are supposed to already have been validated using the<br /> vhost_vdpa_config_validate() function. But I do not know the code<br /> perfectly, and I like to be safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix memory leak in __add_inode_ref()<br /> <br /> Line 1169 (#3) allocates a memory chunk for victim_name by kmalloc(),<br /> but when the function returns in line 1184 (#4) victim_name allocated<br /> by line 1169 (#3) is not freed, which will lead to a memory leak.<br /> There is a similar snippet of code in this function as allocating a memory<br /> chunk for victim_name in line 1104 (#1) as well as releasing the memory<br /> in line 1116 (#2).<br /> <br /> We should kfree() victim_name when the return value of backref_in_log()<br /> is less than zero and before the function returns in line 1184 (#4).<br /> <br /> 1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans,<br /> 1058 struct btrfs_root *root,<br /> 1059 struct btrfs_path *path,<br /> 1060 struct btrfs_root *log_root,<br /> 1061 struct btrfs_inode *dir,<br /> 1062 struct btrfs_inode *inode,<br /> 1063 u64 inode_objectid, u64 parent_objectid,<br /> 1064 u64 ref_index, char *name, int namelen,<br /> 1065 int *search_done)<br /> 1066 {<br /> <br /> 1104 victim_name = kmalloc(victim_name_len, GFP_NOFS);<br /> // #1: kmalloc (victim_name-1)<br /> 1105 if (!victim_name)<br /> 1106 return -ENOMEM;<br /> <br /> 1112 ret = backref_in_log(log_root, &amp;search_key,<br /> 1113 parent_objectid, victim_name,<br /> 1114 victim_name_len);<br /> 1115 if (ret

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: dwmac-rk: fix oob read in rk_gmac_setup<br /> <br /> KASAN reports an out-of-bounds read in rk_gmac_setup on the line:<br /> <br /> while (ops-&gt;regs[i]) {<br /> <br /> This happens for most platforms since the regs flexible array member is<br /> empty, so the memory after the ops structure is being read here. It<br /> seems that mostly this happens to contain zero anyway, so we get lucky<br /> and everything still works.<br /> <br /> To avoid adding redundant data to nearly all the ops structures, add a<br /> new flag to indicate whether the regs field is valid and avoid this loop<br /> when it is not.