Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4: Fix an Oops in pnfs_mark_request_commit() when doing O_DIRECT<br /> <br /> Fix an Oopsable condition in pnfs_mark_request_commit() when we&amp;#39;re<br /> putting a set of writes on the commit list to reschedule them after a<br /> failed pNFS attempt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()<br /> <br /> This module&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: Fix possible use-after-free in wdt_startup()<br /> <br /> This module&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/arm-smmu: Fix arm_smmu_device refcount leak in address translation<br /> <br /> The reference counting issue happens in several exception handling paths<br /> of arm_smmu_iova_to_phys_hard(). When those error scenarios occur, the<br /> function forgets to decrease the refcount of "smmu" increased by<br /> arm_smmu_rpm_get(), causing a refcount leak.<br /> <br /> Fix this issue by jumping to "out" label when those error scenarios<br /> occur.

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 /> iommu/arm-smmu: Fix arm_smmu_device refcount leak when arm_smmu_rpm_get fails<br /> <br /> arm_smmu_rpm_get() invokes pm_runtime_get_sync(), which increases the<br /> refcount of the "smmu" even though the return value is less than 0.<br /> <br /> The reference counting issue happens in some error handling paths of<br /> arm_smmu_rpm_get() in its caller functions. When arm_smmu_rpm_get()<br /> fails, the caller functions forget to decrease the refcount of "smmu"<br /> increased by arm_smmu_rpm_get(), causing a refcount leak.<br /> <br /> Fix this issue by calling pm_runtime_resume_and_get() instead of<br /> pm_runtime_get_sync() in arm_smmu_rpm_get(), which can keep the refcount<br /> balanced in case of failure.

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.