Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: iscsi: Fix conn use after free during resets<br /> <br /> If we haven&amp;#39;t done a unbind target call we can race where<br /> iscsi_conn_teardown wakes up the EH thread and then frees the conn while<br /> those threads are still accessing the conn ehwait.<br /> <br /> We can only do one TMF per session so this just moves the TMF fields from<br /> the conn to the session. We can then rely on the<br /> iscsi_session_teardown-&gt;iscsi_remove_session-&gt;__iscsi_unbind_session call<br /> to remove the target and it&amp;#39;s devices, and know after that point there is<br /> no device or scsi-ml callout trying to access the session.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: megaraid_sas: Fix resource leak in case of probe failure<br /> <br /> The driver doesn&amp;#39;t clean up all the allocated resources properly when<br /> scsi_add_host(), megasas_start_aen() function fails during the PCI device<br /> probe.<br /> <br /> Clean up all those resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: serial: 8250: serial_cs: Fix a memory leak in error handling path<br /> <br /> In the probe function, if the final &amp;#39;serial_config()&amp;#39; fails, &amp;#39;info&amp;#39; is<br /> leaking.<br /> <br /> Add a resource handling path to free this memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Track subprog poke descriptors correctly and fix use-after-free<br /> <br /> Subprograms are calling map_poke_track(), but on program release there is no<br /> hook to call map_poke_untrack(). However, on program release, the aux memory<br /> (and poke descriptor table) is freed even though we still have a reference to<br /> it in the element list of the map aux data. When we run map_poke_run(), we then<br /> end up accessing free&amp;#39;d memory, triggering KASAN in prog_array_map_poke_run():<br /> <br /> [...]<br /> [ 402.824689] BUG: KASAN: use-after-free in prog_array_map_poke_run+0xc2/0x34e<br /> [ 402.824698] Read of size 4 at addr ffff8881905a7940 by task hubble-fgs/4337<br /> [ 402.824705] CPU: 1 PID: 4337 Comm: hubble-fgs Tainted: G I 5.12.0+ #399<br /> [ 402.824715] Call Trace:<br /> [ 402.824719] dump_stack+0x93/0xc2<br /> [ 402.824727] print_address_description.constprop.0+0x1a/0x140<br /> [ 402.824736] ? prog_array_map_poke_run+0xc2/0x34e<br /> [ 402.824740] ? prog_array_map_poke_run+0xc2/0x34e<br /> [ 402.824744] kasan_report.cold+0x7c/0xd8<br /> [ 402.824752] ? prog_array_map_poke_run+0xc2/0x34e<br /> [ 402.824757] prog_array_map_poke_run+0xc2/0x34e<br /> [ 402.824765] bpf_fd_array_map_update_elem+0x124/0x1a0<br /> [...]<br /> <br /> The elements concerned are walked as follows:<br /> <br /> for (i = 0; i aux-&gt;size_poke_tab; i++) {<br /> poke = &amp;elem-&gt;aux-&gt;poke_tab[i];<br /> [...]<br /> <br /> The access to size_poke_tab is a 4 byte read, verified by checking offsets<br /> in the KASAN dump:<br /> <br /> [ 402.825004] The buggy address belongs to the object at ffff8881905a7800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> [ 402.825008] The buggy address is located 320 bytes inside of<br /> 1024-byte region [ffff8881905a7800, ffff8881905a7c00)<br /> <br /> The pahole output of bpf_prog_aux:<br /> <br /> struct bpf_prog_aux {<br /> [...]<br /> /* --- cacheline 5 boundary (320 bytes) --- */<br /> u32 size_poke_tab; /* 320 4 */<br /> [...]<br /> <br /> In general, subprograms do not necessarily manage their own data structures.<br /> For example, BTF func_info and linfo are just pointers to the main program<br /> structure. This allows reference counting and cleanup to be done on the latter<br /> which simplifies their management a bit. The aux-&gt;poke_tab struct, however,<br /> did not follow this logic. The initial proposed fix for this use-after-free<br /> bug further embedded poke data tracking into the subprogram with proper<br /> reference counting. However, Daniel and Alexei questioned why we were treating<br /> these objects special; I agree, its unnecessary. The fix here removes the per<br /> subprogram poke table allocation and map tracking and instead simply points<br /> the aux-&gt;poke_tab pointer at the main programs poke table. This way, map<br /> tracking is simplified to the main program and we do not need to manage them<br /> per subprogram.<br /> <br /> This also means, bpf_prog_free_deferred(), which unwinds the program reference<br /> counting and kfrees objects, needs to ensure that we don&amp;#39;t try to double free<br /> the poke_tab when free&amp;#39;ing the subprog structures. This is easily solved by<br /> NULL&amp;#39;ing the poke_tab pointer. The second detail is to ensure that per<br /> subprogram JIT logic only does fixups on poke_tab[] entries it owns. To do<br /> this, we add a pointer in the poke structure to point at the subprogram value<br /> so JITs can easily check while walking the poke_tab structure if the current<br /> entry belongs to the current program. The aux pointer is stable and therefore<br /> suitable for such comparison. On the jit_subprogs() error path, we omit<br /> cleaning up the poke-&gt;aux field because these are only ever referenced from<br /> the JIT side, but on error we will never make it to the JIT, so its fine to<br /> leave them dangling. Removing these pointers would complicate the error path<br /> for no reason. However, we do need to untrack all poke descriptors from the<br /> main program as otherwise they could race with the freeing of JIT memory from<br /> the subprograms. Lastly, a748c6975dea3 ("bpf: propagate poke des<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized<br /> <br /> This commit fixes a bug (found by syzkaller) that could cause spurious<br /> double-initializations for congestion control modules, which could cause<br /> memory leaks or other problems for congestion control modules (like CDG)<br /> that allocate memory in their init functions.<br /> <br /> The buggy scenario constructed by syzkaller was something like:<br /> <br /> (1) create a TCP socket<br /> (2) initiate a TFO connect via sendto()<br /> (3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),<br /> which calls:<br /> tcp_set_congestion_control() -&gt;<br /> tcp_reinit_congestion_control() -&gt;<br /> tcp_init_congestion_control()<br /> (4) receive ACK, connection is established, call tcp_init_transfer(),<br /> set icsk_ca_initialized=0 (without first calling cc-&gt;release()),<br /> call tcp_init_congestion_control() again.<br /> <br /> Note that in this sequence tcp_init_congestion_control() is called<br /> twice without a cc-&gt;release() call in between. Thus, for CC modules<br /> that allocate memory in their init() function, e.g, CDG, a memory leak<br /> may occur. The syzkaller tool managed to find a reproducer that<br /> triggered such a leak in CDG.<br /> <br /> The bug was introduced when that commit 8919a9b31eb4 ("tcp: Only init<br /> congestion control if not initialized already")<br /> introduced icsk_ca_initialized and set icsk_ca_initialized to 0 in<br /> tcp_init_transfer(), missing the possibility for a sequence like the<br /> one above, where a process could call setsockopt(TCP_CONGESTION) in<br /> state TCP_SYN_SENT (i.e. after the connect() or TFO open sendmsg()),<br /> which would call tcp_init_congestion_control(). It did not intend to<br /> reset any initialization that the user had already explicitly made;<br /> it just missed the possibility of that particular sequence (which<br /> syzkaller managed to find).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-buf/sync_file: Don&amp;#39;t leak fences on merge failure<br /> <br /> Each add_fence() call does a dma_fence_get() on the relevant fence. In<br /> the error path, we weren&amp;#39;t calling dma_fence_put() so all those fences<br /> got leaked. Also, in the krealloc_array failure case, we weren&amp;#39;t<br /> freeing the fences array. Instead, ensure that i and fences are always<br /> zero-initialized and dma_fence_put() all the fences and kfree(fences) on<br /> every error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fddi: fix UAF in fza_probe<br /> <br /> fp is netdev private data and it cannot be<br /> used after free_netdev() call. Using fp after free_netdev()<br /> can cause UAF bug. Fix it by moving free_netdev() after error message.<br /> <br /> TURBOchannel adapter")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: prevent NULL deref in cifs_compose_mount_options()<br /> <br /> The optional @ref parameter might contain an NULL node_name, so<br /> prevent dereferencing it in cifs_compose_mount_options().<br /> <br /> Addresses-Coverity: 1476408 ("Explicit null dereferenced")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libfc: Fix array index out of bound exception<br /> <br /> Fix array index out of bound exception in fc_rport_prli_resp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: validate lwtstate-&gt;data before returning from skb_tunnel_info()<br /> <br /> skb_tunnel_info() returns pointer of lwtstate-&gt;data as ip_tunnel_info<br /> type without validation. lwtstate-&gt;data can have various types such as<br /> mpls_iptunnel_encap, etc and these are not compatible.<br /> So skb_tunnel_info() should validate before returning that pointer.<br /> <br /> Splat looks like:<br /> BUG: KASAN: slab-out-of-bounds in vxlan_get_route+0x418/0x4b0 [vxlan]<br /> Read of size 2 at addr ffff888106ec2698 by task ping/811<br /> <br /> CPU: 1 PID: 811 Comm: ping Not tainted 5.13.0+ #1195<br /> Call Trace:<br /> dump_stack_lvl+0x56/0x7b<br /> print_address_description.constprop.8.cold.13+0x13/0x2ee<br /> ? vxlan_get_route+0x418/0x4b0 [vxlan]<br /> ? vxlan_get_route+0x418/0x4b0 [vxlan]<br /> kasan_report.cold.14+0x83/0xdf<br /> ? vxlan_get_route+0x418/0x4b0 [vxlan]<br /> vxlan_get_route+0x418/0x4b0 [vxlan]<br /> [ ... ]<br /> vxlan_xmit_one+0x148b/0x32b0 [vxlan]<br /> [ ... ]<br /> vxlan_xmit+0x25c5/0x4780 [vxlan]<br /> [ ... ]<br /> dev_hard_start_xmit+0x1ae/0x6e0<br /> __dev_queue_xmit+0x1f39/0x31a0<br /> [ ... ]<br /> neigh_xmit+0x2f9/0x940<br /> mpls_xmit+0x911/0x1600 [mpls_iptunnel]<br /> lwtunnel_xmit+0x18f/0x450<br /> ip_finish_output2+0x867/0x2040<br /> [ ... ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: fix UAF in tlan_remove_one<br /> <br /> priv is netdev private data and it cannot be<br /> used after free_netdev() call. Using priv after free_netdev()<br /> can cause UAF bug. Fix it by moving free_netdev() at the end of the<br /> function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qcom/emac: fix UAF in emac_remove<br /> <br /> adpt is netdev private data and it cannot be<br /> used after free_netdev() call. Using adpt after free_netdev()<br /> can cause UAF bug. Fix it by moving free_netdev() at the end of the<br /> function.