Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: rk817: Fix node refcount leak<br /> <br /> Dan Carpenter reports that the Smatch static checker warning has found<br /> that there is another refcount leak in the probe function. While<br /> of_node_put() was added in one of the return paths, it should in<br /> fact be added for ALL return paths that return an error and at driver<br /> removal time.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()<br /> <br /> In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the<br /> reference count of bh when the call to nilfs_dat_translate() fails. If<br /> the reference count hits 0 and its owner page gets unlocked, bh may be<br /> freed. However, bh-&gt;b_page is dereferenced to put the page after that,<br /> which may result in a use-after-free bug. This patch moves the release<br /> operation after unlocking and putting the page.<br /> <br /> NOTE: The function in question is only called in GC, and in combination<br /> with current userland tools, address translation using DAT does not occur<br /> in that function, so the code path that causes this issue will not be<br /> executed. However, it is possible to run that code path by intentionally<br /> modifying the userland GC library or by calling the GC ioctl directly.<br /> <br /> [konishi.ryusuke@gmail.com: NOTE added to the commit log]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix UAF in cifs_demultiplex_thread()<br /> <br /> There is a UAF when xfstests on cifs:<br /> <br /> BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160<br /> Read of size 4 at addr ffff88810103fc08 by task cifsd/923<br /> <br /> CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_report+0x171/0x472<br /> kasan_report+0xad/0x130<br /> kasan_check_range+0x145/0x1a0<br /> smb2_is_network_name_deleted+0x27/0x160<br /> cifs_demultiplex_thread.cold+0x172/0x5a4<br /> kthread+0x165/0x1a0<br /> ret_from_fork+0x1f/0x30<br /> <br /> <br /> Allocated by task 923:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_slab_alloc+0x54/0x60<br /> kmem_cache_alloc+0x147/0x320<br /> mempool_alloc+0xe1/0x260<br /> cifs_small_buf_get+0x24/0x60<br /> allocate_buffers+0xa1/0x1c0<br /> cifs_demultiplex_thread+0x199/0x10d0<br /> kthread+0x165/0x1a0<br /> ret_from_fork+0x1f/0x30<br /> <br /> Freed by task 921:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x143/0x1b0<br /> kmem_cache_free+0xe3/0x4d0<br /> cifs_small_buf_release+0x29/0x90<br /> SMB2_negotiate+0x8b7/0x1c60<br /> smb2_negotiate+0x51/0x70<br /> cifs_negotiate_protocol+0xf0/0x160<br /> cifs_get_smb_ses+0x5fa/0x13c0<br /> mount_get_conns+0x7a/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The UAF is because:<br /> <br /> mount(pid: 921) | cifsd(pid: 923)<br /> -------------------------------|-------------------------------<br /> | cifs_demultiplex_thread<br /> SMB2_negotiate |<br /> cifs_send_recv |<br /> compound_send_recv |<br /> smb_send_rqst |<br /> wait_for_response |<br /> wait_event_state [1] |<br /> | standard_receive3<br /> | cifs_handle_standard<br /> | handle_mid<br /> | mid-&gt;resp_buf = buf; [2]<br /> | dequeue_mid [3]<br /> KILL the process [4] |<br /> resp_iov[i].iov_base = buf |<br /> free_rsp_buf [5] |<br /> | is_network_name_deleted [6]<br /> | callback<br /> <br /> 1. After send request to server, wait the response until<br /> mid-&gt;mid_state != SUBMITTED;<br /> 2. Receive response from server, and set it to mid;<br /> 3. Set the mid state to RECEIVED;<br /> 4. Kill the process, the mid state already RECEIVED, get 0;<br /> 5. Handle and release the negotiate response;<br /> 6. UAF.<br /> <br /> It can be easily reproduce with add some delay in [3] - [6].<br /> <br /> Only sync call has the problem since async call&amp;#39;s callback is<br /> executed in cifsd process.<br /> <br /> Add an extra state to mark the mid state to READY before wakeup the<br /> waitter, then it can get the resp safely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: remove BUG() after failure to insert delayed dir index item<br /> <br /> Instead of calling BUG() when we fail to insert a delayed dir index item<br /> into the delayed node&amp;#39;s tree, we can just release all the resources we<br /> have allocated/acquired before and return the error to the caller. This is<br /> fine because all existing call chains undo anything they have done before<br /> calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending<br /> snapshots in the transaction commit path).<br /> <br /> So remove the BUG() call and do proper error handling.<br /> <br /> This relates to a syzbot report linked below, but does not fix it because<br /> it only prevents hitting a BUG(), it does not fix the issue where somehow<br /> we attempt to use twice the same index number for different index items.

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 /> net: fix possible store tearing in neigh_periodic_work()<br /> <br /> While looking at a related syzbot report involving neigh_periodic_work(),<br /> I found that I forgot to add an annotation when deleting an<br /> RCU protected item from a list.<br /> <br /> Readers use rcu_deference(*np), we need to use either<br /> rcu_assign_pointer() or WRITE_ONCE() on writer side<br /> to prevent store tearing.<br /> <br /> I use rcu_assign_pointer() to have lockdep support,<br /> this was the choice made in neigh_flush_dev().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"<br /> <br /> This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239.<br /> <br /> The commit above is reverted as it did not solve the original issue.<br /> <br /> gsm_cleanup_mux() tries to free up the virtual ttys by calling<br /> gsm_dlci_release() for each available DLCI. There, dlci_put() is called to<br /> decrease the reference counter for the DLCI via tty_port_put() which<br /> finally calls gsm_dlci_free(). This already clears the pointer which is<br /> being checked in gsm_cleanup_mux() before calling gsm_dlci_release().<br /> Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux()<br /> as done in the reverted commit. The commit introduces a null pointer<br /> dereference:<br /> <br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x156/0x420<br /> ? search_exception_tables+0x37/0x50<br /> ? fixup_exception+0x21/0x310<br /> ? exc_page_fault+0x69/0x150<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? tty_port_put+0x19/0xa0<br /> gsmtty_cleanup+0x29/0x80 [n_gsm]<br /> release_one_tty+0x37/0xe0<br /> process_one_work+0x1e6/0x3e0<br /> worker_thread+0x4c/0x3d0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe1/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2f/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> The actual issue is that nothing guards dlci_put() from being called<br /> multiple times while the tty driver was triggered but did not yet finished<br /> calling gsm_dlci_free().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit<br /> <br /> The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)<br /> service, which allows to wakup device when the system is in S5 (Soft-Off<br /> state). This OOB service can be enabled/disabled from BIOS settings. When<br /> enabled, the ISH device gets PME wake capability. To enable PME wakeup,<br /> driver also needs to enable ACPI GPE bit.<br /> <br /> On resume, BIOS will clear the wakeup bit. So driver need to re-enable it<br /> in resume function to keep the next wakeup capability. But this BIOS<br /> clearing of wakeup bit doesn&amp;#39;t decrement internal OS GPE reference count,<br /> so this reenabling on every resume will cause reference count to overflow.<br /> <br /> So first disable and reenable ACPI GPE bit using acpi_disable_gpe().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets<br /> <br /> With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages<br /> sent from one TCP socket (s1) to actually egress from another TCP<br /> socket (s2):<br /> <br /> tcp_bpf_sendmsg(s1) // = sk_prot-&gt;sendmsg<br /> tcp_bpf_send_verdict(s1) // __SK_REDIRECT case<br /> tcp_bpf_sendmsg_redir(s2)<br /> tcp_bpf_push_locked(s2)<br /> tcp_bpf_push(s2)<br /> tcp_rate_check_app_limited(s2) // expects tcp_sock<br /> tcp_sendmsg_locked(s2) // ditto<br /> <br /> There is a hard-coded assumption in the call-chain, that the egress<br /> socket (s2) is a TCP socket.<br /> <br /> However in commit 122e6c79efe1 ("sock_map: Update sock type checks for<br /> UDP") we have enabled redirects to non-TCP sockets. This was done for the<br /> sake of BPF sk_skb programs. There was no indention to support sk_msg<br /> send-to-egress use case.<br /> <br /> As a result, attempts to send-to-egress through a non-TCP socket lead to a<br /> crash due to invalid downcast from sock to tcp_sock:<br /> <br /> BUG: kernel NULL pointer dereference, address: 000000000000002f<br /> ...<br /> Call Trace:<br /> <br /> ? show_regs+0x60/0x70<br /> ? __die+0x1f/0x70<br /> ? page_fault_oops+0x80/0x160<br /> ? do_user_addr_fault+0x2d7/0x800<br /> ? rcu_is_watching+0x11/0x50<br /> ? exc_page_fault+0x70/0x1c0<br /> ? asm_exc_page_fault+0x27/0x30<br /> ? tcp_tso_segs+0x14/0xa0<br /> tcp_write_xmit+0x67/0xce0<br /> __tcp_push_pending_frames+0x32/0xf0<br /> tcp_push+0x107/0x140<br /> tcp_sendmsg_locked+0x99f/0xbb0<br /> tcp_bpf_push+0x19d/0x3a0<br /> tcp_bpf_sendmsg_redir+0x55/0xd0<br /> tcp_bpf_send_verdict+0x407/0x550<br /> tcp_bpf_sendmsg+0x1a1/0x390<br /> inet_sendmsg+0x6a/0x70<br /> sock_sendmsg+0x9d/0xc0<br /> ? sockfd_lookup_light+0x12/0x80<br /> __sys_sendto+0x10e/0x160<br /> ? syscall_enter_from_user_mode+0x20/0x60<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> ? lockdep_hardirqs_on+0x82/0x110<br /> __x64_sys_sendto+0x1f/0x30<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg<br /> program to prevent the crash. When attempted, user will receive an EACCES<br /> error from send/sendto/sendmsg() syscall.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: nfc: llcp: Add lock when modifying device list<br /> <br /> The device list needs its associated lock held when modifying it, or the<br /> list could become corrupted, as syzbot discovered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet<br /> <br /> Only skip the code path trying to access the rfc1042 headers when the<br /> buffer is too small, so the driver can still process packets without<br /> rfc1042 headers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()<br /> <br /> Including the transhdrlen in length is a problem when the packet is<br /> partially filled (e.g. something like send(MSG_MORE) happened previously)<br /> when appending to an IPv4 or IPv6 packet as we don&amp;#39;t want to repeat the<br /> transport header or account for it twice. This can happen under some<br /> circumstances, such as splicing into an L2TP socket.<br /> <br /> The symptom observed is a warning in __ip6_append_data():<br /> <br /> WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800<br /> <br /> that occurs when MSG_SPLICE_PAGES is used to append more data to an already<br /> partially occupied skbuff. The warning occurs when &amp;#39;copy&amp;#39; is larger than<br /> the amount of data in the message iterator. This is because the requested<br /> length includes the transport header length when it shouldn&amp;#39;t. This can be<br /> triggered by, for example:<br /> <br /> sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);<br /> bind(sfd, ...); // ::1<br /> connect(sfd, ...); // ::1 port 7<br /> send(sfd, buffer, 4100, MSG_MORE);<br /> sendfile(sfd, dfd, NULL, 1024);<br /> <br /> Fix this by only adding transhdrlen into the length if the write queue is<br /> empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.<br /> <br /> l2tp_ip_sendmsg() looks like it won&amp;#39;t suffer from this problem as it builds<br /> the UDP packet itself.