Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> erofs: fix missing xas_retry() in fscache mode<br /> <br /> The xarray iteration only holds the RCU read lock and thus may encounter<br /> XA_RETRY_ENTRY if there&amp;#39;s process modifying the xarray concurrently.<br /> This will cause oops when referring to the invalid entry.<br /> <br /> Fix this by adding the missing xas_retry(), which will make the<br /> iteration wind back to the root node if XA_RETRY_ENTRY is encountered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: close race conditions on sk_receive_queue<br /> <br /> sk-&gt;sk_receive_queue is protected by skb queue lock, but for KCM<br /> sockets its RX path takes mux-&gt;rx_lock to protect more than just<br /> skb queue. However, kcm_recvmsg() still only grabs the skb queue<br /> lock, so race conditions still exist.<br /> <br /> We can teach kcm_recvmsg() to grab mux-&gt;rx_lock too but this would<br /> introduce a potential performance regression as struct kcm_mux can<br /> be shared by multiple KCM sockets.<br /> <br /> So we have to enforce skb queue lock in requeue_rx_msgs() and handle<br /> skb peek case carefully in kcm_wait_data(). Fortunately,<br /> skb_recv_datagram() already handles it nicely and is widely used by<br /> other sockets, we can just switch to skb_recv_datagram() after<br /> getting rid of the unnecessary sock lock in kcm_recvmsg() and<br /> kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,<br /> so it is safe to get rid of this check too.<br /> <br /> I ran the original syzbot reproducer for 30 min without seeing any<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ena: Fix error handling in ena_init()<br /> <br /> The ena_init() won&amp;#39;t destroy workqueue created by<br /> create_singlethread_workqueue() when pci_register_driver() failed.<br /> Call destroy_workqueue() when pci_register_driver() failed to prevent the<br /> resource leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: switchdev: Fix memory leaks when changing VLAN protocol<br /> <br /> The bridge driver can offload VLANs to the underlying hardware either<br /> via switchdev or the 8021q driver. When the former is used, the VLAN is<br /> marked in the bridge driver with the &amp;#39;BR_VLFLAG_ADDED_BY_SWITCHDEV&amp;#39;<br /> private flag.<br /> <br /> To avoid the memory leaks mentioned in the cited commit, the bridge<br /> driver will try to delete a VLAN via the 8021q driver if the VLAN is not<br /> marked with the previously mentioned flag.<br /> <br /> When the VLAN protocol of the bridge changes, switchdev drivers are<br /> notified via the &amp;#39;SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL&amp;#39; attribute, but<br /> the 8021q driver is also called to add the existing VLANs with the new<br /> protocol and delete them with the old protocol.<br /> <br /> In case the VLANs were offloaded via switchdev, the above behavior is<br /> both redundant and buggy. Redundant because the VLANs are already<br /> programmed in hardware and drivers that support VLAN protocol change<br /> (currently only mlx5) change the protocol upon the switchdev attribute<br /> notification. Buggy because the 8021q driver is called despite these<br /> VLANs being marked with &amp;#39;BR_VLFLAG_ADDED_BY_SWITCHDEV&amp;#39;. This leads to<br /> memory leaks [1] when the VLANs are deleted.<br /> <br /> Fix by not calling the 8021q driver for VLANs that were already<br /> programmed via switchdev.<br /> <br /> [1]<br /> unreferenced object 0xffff8881f6771200 (size 256):<br /> comm "ip", pid 446855, jiffies 4298238841 (age 55.240s)<br /> hex dump (first 32 bytes):<br /> 00 00 7f 0e 83 88 ff ff 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 /> [] vlan_vid_add+0x437/0x750<br /> [] __br_vlan_set_proto+0x289/0x920<br /> [] br_changelink+0x3d6/0x13f0<br /> [] __rtnl_newlink+0x8ae/0x14c0<br /> [] rtnl_newlink+0x5f/0x90<br /> [] rtnetlink_rcv_msg+0x336/0xa00<br /> [] netlink_rcv_skb+0x11d/0x340<br /> [] netlink_unicast+0x438/0x710<br /> [] netlink_sendmsg+0x788/0xc40<br /> [] sock_sendmsg+0xb0/0xe0<br /> [] ____sys_sendmsg+0x4ff/0x6d0<br /> [] ___sys_sendmsg+0x12e/0x1b0<br /> [] __sys_sendmsg+0xab/0x130<br /> [] do_syscall_64+0x3d/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drbd: use after free in drbd_create_device()<br /> <br /> The drbd_destroy_connection() frees the "connection" so use the _safe()<br /> iterator to prevent a use after free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: fix a memory leak in nvmet_auth_set_key<br /> <br /> When changing dhchap secrets we need to release the old<br /> secrets as well.<br /> <br /> kmemleak complaint:<br /> --<br /> unreferenced object 0xffff8c7f44ed8180 (size 64):<br /> comm "check", pid 7304, jiffies 4295686133 (age 72034.246s)<br /> hex dump (first 32 bytes):<br /> 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq<br /> 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8<br /> backtrace:<br /> [] kstrdup+0x2e/0x60<br /> [] 0xffffffffc0e07ee6<br /> [] 0xffffffffc0dff783<br /> [] configfs_write_iter+0xb1/0x120<br /> [] vfs_write+0x2be/0x3c0<br /> [] ksys_write+0x5f/0xe0<br /> [] do_syscall_64+0x38/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: don&amp;#39;t leak tagger-owned storage on switch driver unbind<br /> <br /> In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned<br /> storage for private and shared data"), we had a call to<br /> tag_ops-&gt;disconnect(dst) issued from dsa_tree_free(), which is called at<br /> tree teardown time.<br /> <br /> There were problems with connecting to a switch tree as a whole, so this<br /> got reworked to connecting to individual switches within the tree. In<br /> this process, tag_ops-&gt;disconnect(ds) was made to be called only from<br /> switch.c (cross-chip notifiers emitted as a result of dynamic tag proto<br /> changes), but the normal driver teardown code path wasn&amp;#39;t replaced with<br /> anything.<br /> <br /> Solve this problem by adding a function that does the opposite of<br /> dsa_switch_setup_tag_protocol(), which is called from the equivalent<br /> spot in dsa_switch_teardown(). The positioning here also ensures that we<br /> won&amp;#39;t have any use-after-free in tagging protocol (*rcv) ops, since the<br /> teardown sequence is as follows:<br /> <br /> dsa_tree_teardown<br /> -&gt; dsa_tree_teardown_master<br /> -&gt; dsa_master_teardown<br /> -&gt; unsets master-&gt;dsa_ptr, making no further packets match the<br /> ETH_P_XDSA packet type handler<br /> -&gt; dsa_tree_teardown_ports<br /> -&gt; dsa_port_teardown<br /> -&gt; dsa_slave_destroy<br /> -&gt; unregisters DSA net devices, there is even a synchronize_net()<br /> in unregister_netdevice_many()<br /> -&gt; dsa_tree_teardown_switches<br /> -&gt; dsa_switch_teardown<br /> -&gt; dsa_switch_teardown_tag_protocol<br /> -&gt; finally frees the tagger-owned storage

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix missing xas_retry() calls in xarray iteration<br /> <br /> netfslib has a number of places in which it performs iteration of an xarray<br /> whilst being under the RCU read lock. It *should* call xas_retry() as the<br /> first thing inside of the loop and do "continue" if it returns true in case<br /> the xarray walker passed out a special value indicating that the walk needs<br /> to be redone from the root[*].<br /> <br /> Fix this by adding the missing retry checks.<br /> <br /> [*] I wonder if this should be done inside xas_find(), xas_next_node() and<br /> suchlike, but I&amp;#39;m told that&amp;#39;s not an simple change to effect.<br /> <br /> This can cause an oops like that below. Note the faulting address - this<br /> is an internal value (|0x2) returned from xarray.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000402<br /> ...<br /> RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs]<br /> ...<br /> Call Trace:<br /> netfs_rreq_assess+0xa6/0x240 [netfs]<br /> netfs_readpage+0x173/0x3b0 [netfs]<br /> ? init_wait_var_entry+0x50/0x50<br /> filemap_read_page+0x33/0xf0<br /> filemap_get_pages+0x2f2/0x3f0<br /> filemap_read+0xaa/0x320<br /> ? do_filp_open+0xb2/0x150<br /> ? rmqueue+0x3be/0xe10<br /> ceph_read_iter+0x1fe/0x680 [ceph]<br /> ? new_sync_read+0x115/0x1a0<br /> new_sync_read+0x115/0x1a0<br /> vfs_read+0xf3/0x180<br /> ksys_read+0x5f/0xe0<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Changes:<br /> ========<br /> ver #2)<br /> - Changed an unsigned int to a size_t to reduce the likelihood of an<br /> overflow as per Willy&amp;#39;s suggestion.<br /> - Added an additional patch to fix the maths.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: Fix skb leak in x25_lapb_receive_frame()<br /> <br /> x25_lapb_receive_frame() using skb_copy() to get a private copy of<br /> skb, the new skb should be freed in the undersized/fragmented skb<br /> error handling path. Otherwise there is a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Fix null pointer dereference in ftrace_add_mod()<br /> <br /> The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next}<br /> of @ftrace_mode-&gt;list are NULL, it&amp;#39;s not a valid state to call list_del().<br /> If kstrdup() for @ftrace_mod-&gt;{func|module} fails, it goes to @out_free<br /> tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del()<br /> will write prev-&gt;next and next-&gt;prev, where null pointer dereference<br /> happens.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> Oops: 0002 [#1] PREEMPT SMP NOPTI<br /> Call Trace:<br /> <br /> ftrace_mod_callback+0x20d/0x220<br /> ? do_filp_open+0xd9/0x140<br /> ftrace_process_regex.isra.51+0xbf/0x130<br /> ftrace_regex_write.isra.52.part.53+0x6e/0x90<br /> vfs_write+0xee/0x3a0<br /> ? __audit_filter_op+0xb1/0x100<br /> ? auditd_test_task+0x38/0x50<br /> ksys_write+0xa5/0xe0<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> Kernel panic - not syncing: Fatal exception<br /> <br /> So call INIT_LIST_HEAD() to initialize the list member to fix this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: Fix memory leak of nsim_dev-&gt;fa_cookie<br /> <br /> kmemleak reports this issue:<br /> <br /> unreferenced object 0xffff8881bac872d0 (size 8):<br /> comm "sh", pid 58603, jiffies 4481524462 (age 68.065s)<br /> hex dump (first 8 bytes):<br /> 04 00 00 00 de ad be ef ........<br /> backtrace:<br /> [] __kmalloc+0x49/0x150<br /> [] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim]<br /> [] full_proxy_write+0xf3/0x180<br /> [] vfs_write+0x1c5/0xaf0<br /> [] ksys_write+0xed/0x1c0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The issue occurs in the following scenarios:<br /> <br /> nsim_dev_trap_fa_cookie_write()<br /> kmalloc() fa_cookie<br /> nsim_dev-&gt;fa_cookie = fa_cookie<br /> ..<br /> nsim_drv_remove()<br /> <br /> The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To<br /> fix, add kfree(nsim_dev-&gt;fa_cookie) to nsim_drv_remove().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390: avoid using global register for current_stack_pointer<br /> <br /> Commit 30de14b1884b ("s390: current_stack_pointer shouldn&amp;#39;t be a<br /> function") made current_stack_pointer a global register variable like<br /> on many other architectures. Unfortunately on s390 it uncovers old<br /> gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87<br /> ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")]<br /> and backported to gcc-8.4 and later. Due to this bug gcc versions prior<br /> to 8.4 generate broken code which leads to stack corruptions.<br /> <br /> Current minimal gcc version required to build the kernel is declared<br /> as 5.1. It is not possible to fix all old gcc versions, so work<br /> around this problem by avoiding using global register variable for<br /> current_stack_pointer.