Vulnerabilities

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 /> 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 /> platform/x86: think-lmi: Fix reference leak<br /> <br /> If a duplicate attribute is found using kset_find_obj(), a reference<br /> to that attribute is returned which needs to be disposed accordingly<br /> using kobject_put(). Move the setting name validation into a separate<br /> function to allow for this change without having to duplicate the<br /> cleanup code for this setting.<br /> As a side note, a very similar bug was fixed in<br /> commit 7295a996fdab ("platform/x86: dell-sysman: Fix reference leak"),<br /> so it seems that the bug was copied from that driver.<br /> <br /> Compile-tested only.

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 /> 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 /> erofs: fix memory leak of LZMA global compressed deduplication<br /> <br /> When stressing microLZMA EROFS images with the new global compressed<br /> deduplication feature enabled (`-Ededupe`), I found some short-lived<br /> temporary pages weren&amp;#39;t properly released, which could slowly cause<br /> unexpected OOMs hours later.<br /> <br /> Let&amp;#39;s fix it now (LZ4 and DEFLATE don&amp;#39;t have this issue.)

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg<br /> <br /> syzbot reported the following uninit-value access issue:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x21c/0x280 lib/dump_stack.c:118<br /> kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121<br /> __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]<br /> smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737<br /> usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032<br /> usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241<br /> usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272<br /> really_probe+0xf20/0x20b0 drivers/base/dd.c:529<br /> driver_probe_device+0x293/0x390 drivers/base/dd.c:701<br /> __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807<br /> bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431<br /> __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873<br /> device_initial_probe+0x4a/0x60 drivers/base/dd.c:920<br /> bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491<br /> device_add+0x3b0e/0x40d0 drivers/base/core.c:2680<br /> usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554<br /> hub_port_connect drivers/usb/core/hub.c:5208 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]<br /> port_event drivers/usb/core/hub.c:5494 [inline]<br /> hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576<br /> process_one_work+0x1688/0x2140 kernel/workqueue.c:2269<br /> worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415<br /> kthread+0x551/0x590 kernel/kthread.c:292<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293<br /> <br /> Local variable ----buf.i87@smsc75xx_bind created at:<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]<br /> smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]<br /> smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482<br /> <br /> This issue is caused because usbnet_read_cmd() reads less bytes than requested<br /> (zero byte in the reproducer). In this case, &amp;#39;buf&amp;#39; is not properly filled.<br /> <br /> This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads<br /> less bytes than requested.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: sony: Fix a potential memory leak in sony_probe()<br /> <br /> If an error occurs after a successful usb_alloc_urb() call, usb_free_urb()<br /> should be called.