Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove<br /> <br /> This fixes the following crash:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]<br /> Read of size 8 at addr ffff888136335380 by task kworker/6:0/140241<br /> <br /> CPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G E 6.14.0-rc6+ #1<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024<br /> Workqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x51/0x70<br /> print_address_description.constprop.0+0x27/0x320<br /> ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]<br /> print_report+0x3e/0x70<br /> kasan_report+0xab/0xe0<br /> ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]<br /> rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]<br /> ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]<br /> ? __pfx___schedule+0x10/0x10<br /> ? kick_pool+0x3b/0x270<br /> process_one_work+0x357/0x660<br /> worker_thread+0x390/0x4c0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x190/0x1d0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2d/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 161446:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x10/0x30<br /> __kasan_kmalloc+0x7b/0x90<br /> __kmalloc_noprof+0x1a7/0x470<br /> memstick_alloc_host+0x1f/0xe0 [memstick]<br /> rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]<br /> platform_probe+0x60/0xe0<br /> call_driver_probe+0x35/0x120<br /> really_probe+0x123/0x410<br /> __driver_probe_device+0xc7/0x1e0<br /> driver_probe_device+0x49/0xf0<br /> __device_attach_driver+0xc6/0x160<br /> bus_for_each_drv+0xe4/0x160<br /> __device_attach+0x13a/0x2b0<br /> bus_probe_device+0xbd/0xd0<br /> device_add+0x4a5/0x760<br /> platform_device_add+0x189/0x370<br /> mfd_add_device+0x587/0x5e0<br /> mfd_add_devices+0xb1/0x130<br /> rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]<br /> usb_probe_interface+0x15c/0x460<br /> call_driver_probe+0x35/0x120<br /> really_probe+0x123/0x410<br /> __driver_probe_device+0xc7/0x1e0<br /> driver_probe_device+0x49/0xf0<br /> __device_attach_driver+0xc6/0x160<br /> bus_for_each_drv+0xe4/0x160<br /> __device_attach+0x13a/0x2b0<br /> rebind_marked_interfaces.isra.0+0xcc/0x110<br /> usb_reset_device+0x352/0x410<br /> usbdev_do_ioctl+0xe5c/0x1860<br /> usbdev_ioctl+0xa/0x20<br /> __x64_sys_ioctl+0xc5/0xf0<br /> do_syscall_64+0x59/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 161506:<br /> kasan_save_stack+0x20/0x40<br /> kasan_save_track+0x10/0x30<br /> kasan_save_free_info+0x36/0x60<br /> __kasan_slab_free+0x34/0x50<br /> kfree+0x1fd/0x3b0<br /> device_release+0x56/0xf0<br /> kobject_cleanup+0x73/0x1c0<br /> rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]<br /> platform_remove+0x2f/0x50<br /> device_release_driver_internal+0x24b/0x2e0<br /> bus_remove_device+0x124/0x1d0<br /> device_del+0x239/0x530<br /> platform_device_del.part.0+0x19/0xe0<br /> platform_device_unregister+0x1c/0x40<br /> mfd_remove_devices_fn+0x167/0x170<br /> device_for_each_child_reverse+0xc9/0x130<br /> mfd_remove_devices+0x6e/0xa0<br /> rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]<br /> usb_unbind_interface+0xf3/0x3f0<br /> device_release_driver_internal+0x24b/0x2e0<br /> proc_disconnect_claim+0x13d/0x220<br /> usbdev_do_ioctl+0xb5e/0x1860<br /> usbdev_ioctl+0xa/0x20<br /> __x64_sys_ioctl+0xc5/0xf0<br /> do_syscall_64+0x59/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x20/0x40<br /> kasan_record_aux_stack+0x85/0x90<br /> insert_work+0x29/0x100<br /> __queue_work+0x34a/0x540<br /> call_timer_fn+0x2a/0x160<br /> expire_timers+0x5f/0x1f0<br /> __run_timer_base.part.0+0x1b6/0x1e0<br /> run_timer_softirq+0x8b/0xe0<br /> handle_softirqs+0xf9/0x360<br /> __irq_exit_rcu+0x114/0x130<br /> sysvec_apic_timer_interrupt+0x72/0x90<br /> asm_sysvec_apic_timer_interrupt+0x16/0x20<br /> <br /> Second to last potentially related work creation:<br /> kasan_save_stack+0x20/0x40<br /> kasan_record_aux_stack+0x85/0x90<br /> insert_work+0x29/0x100<br /> __queue_work+0x34a/0x540<br /> call_timer_fn+0x2a/0x160<br /> expire_timers+0x5f/0x1f0<br /> __run_timer_base.part.0+0x1b6/0x1e0<br /> run_timer_softirq+0x8b/0xe0<br /> handle_softirqs+0xf9/0x<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: socket: Lookup orig tuple for IPv6 SNAT<br /> <br /> nf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets to<br /> restore the original 5-tuple in case of SNAT, to be able to find the<br /> right socket (if any). Then socket_match() can correctly check whether<br /> the socket was transparent.<br /> <br /> However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks this<br /> conntrack lookup, making xt_socket fail to match on the socket when the<br /> packet was SNATed. Add the same logic to nf_sk_lookup_slow_v6.<br /> <br /> IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as<br /> pods&amp;#39; addresses are in the fd00::/8 ULA subnet and need to be replaced<br /> with the node&amp;#39;s external address. Cilium leverages Envoy to enforce L7<br /> policies, and Envoy uses transparent sockets. Cilium inserts an iptables<br /> prerouting rule that matches on `-m socket --transparent` and redirects<br /> the packets to localhost, but it fails to match SNATed IPv6 packets due<br /> to that missing conntrack lookup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Don&amp;#39;t skip on Stopped - Length Invalid<br /> <br /> Up until commit d56b0b2ab142 ("usb: xhci: ensure skipped isoc TDs are<br /> returned when isoc ring is stopped") in v6.11, the driver didn&amp;#39;t skip<br /> missed isochronous TDs when handling Stoppend and Stopped - Length<br /> Invalid events. Instead, it erroneously cleared the skip flag, which<br /> would cause the ring to get stuck, as future events won&amp;#39;t match the<br /> missed TD which is never removed from the queue until it&amp;#39;s cancelled.<br /> <br /> This buggy logic seems to have been in place substantially unchanged<br /> since the 3.x series over 10 years ago, which probably speaks first<br /> and foremost about relative rarity of this case in normal usage, but<br /> by the spec I see no reason why it shouldn&amp;#39;t be possible.<br /> <br /> After d56b0b2ab142, TDs are immediately skipped when handling those<br /> Stopped events. This poses a potential problem in case of Stopped -<br /> Length Invalid, which occurs either on completed TDs (likely already<br /> given back) or Link and No-Op TRBs. Such event won&amp;#39;t be recognized<br /> as matching any TD (unless it&amp;#39;s the rare Link TRB inside a TD) and<br /> will result in skipping all pending TDs, giving them back possibly<br /> before they are done, risking isoc data loss and maybe UAF by HW.<br /> <br /> As a compromise, don&amp;#39;t skip and don&amp;#39;t clear the skip flag on this<br /> kind of event. Then the next event will skip missed TDs. A downside<br /> of not handling Stopped - Length Invalid on a Link inside a TD is<br /> that if the TD is cancelled, its actual length will not be updated<br /> to account for TRBs (silently) completed before the TD was stopped.<br /> <br /> I had no luck producing this sequence of completion events so there<br /> is no compelling demonstration of any resulting disaster. It may be<br /> a very rare, obscure condition. The sole motivation for this patch<br /> is that if such unlikely event does occur, I&amp;#39;d rather risk reporting<br /> a cancelled partially done isoc frame as empty than gamble with UAF.<br /> <br /> This will be fixed more properly by looking at Stopped event&amp;#39;s TRB<br /> pointer when making skipping decisions, but such rework is unlikely<br /> to be backported to v6.12, which will stay around for a few years.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Apply the link chain quirk on NEC isoc endpoints<br /> <br /> Two clearly different specimens of NEC uPD720200 (one with start/stop<br /> bug, one without) were seen to cause IOMMU faults after some Missed<br /> Service Errors. Faulting address is immediately after a transfer ring<br /> segment and patched dynamic debug messages revealed that the MSE was<br /> received when waiting for a TD near the end of that segment:<br /> <br /> [ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0<br /> [ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000]<br /> [ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]<br /> <br /> It gets even funnier if the next page is a ring segment accessible to<br /> the HC. Below, it reports MSE in segment at ff1e8000, plows through a<br /> zero-filled page at ff1e9000 and starts reporting events for TRBs in<br /> page at ff1ea000 every microframe, instead of jumping to seg ff1e6000.<br /> <br /> [ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0<br /> [ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0<br /> [ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint<br /> [ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.<br /> [ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint<br /> [ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31<br /> [ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> [ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint<br /> [ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31<br /> [ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> <br /> At some point completion events change from Isoch Buffer Overrun to<br /> Short Packet and the HC finally finds cycle bit mismatch in ff1ec000.<br /> <br /> [ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13<br /> [ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> [ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13<br /> [ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820<br /> [ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2<br /> <br /> It&amp;#39;s possible that data from the isochronous device were written to<br /> random buffers of pending TDs on other endpoints (either IN or OUT),<br /> other devices or even other HCs in the same IOMMU domain.<br /> <br /> Lastly, an error from a different USB device on another HC. Was it<br /> caused by the above? I don&amp;#39;t know, but it may have been. The disk<br /> was working without any other issues and generated PCIe traffic to<br /> starve the NEC of upstream BW and trigger those MSEs. The two HCs<br /> shared one x1 slot by means of a commercial "PCIe splitter" board.<br /> <br /> [ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd<br /> [ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s<br /> [ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00<br /> [ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0<br /> <br /> Fortunately, it appears that this ridiculous bug is avoided by setting<br /> the chain bit of Link TRBs on isochronous rings. Other ancient HCs are<br /> known which also expect the bit to be set and they ignore Link TRBs if<br /> it&amp;#39;s not. Reportedly, 0.95 spec guaranteed that the bit is set.<br /> <br /> The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reports<br /> tens of MSEs per second and runs into the bug within seconds. Chaining<br /> Link TRBs allows the same workload to run for many minutes, many times.<br /> <br /> No ne<br /> ---truncated---

Mattermost versions 10.4.x

A vulnerability, which was classified as critical, was found in PCMan FTP Server 2.0.7. Affected is an unknown function of the component HOST Command Handler. The manipulation leads to buffer overflow. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in PCMan FTP Server 2.0.7 and classified as critical. Affected by this issue is some unknown functionality of the component MODE Command Handler. The manipulation leads to buffer overflow. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.

A vulnerability has been found in PCMan FTP Server 2.0.7 and classified as critical. Affected by this vulnerability is an unknown functionality of the component LANG Command Handler. The manipulation leads to buffer overflow. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.

Mattermost Plugin MSTeams versions

The WP STAGING Pro WordPress Backup Plugin for WordPress is vulnerable to Information Exposure in all versions up to and including 6.1.2 due to missing capability checks on the getOutdatedPluginsRequest() function. This makes it possible for unauthenticated attackers to reveal outdated installed active or inactive plugins.

A vulnerability classified as critical was found in lm-sys fastchat up to 0.2.36. This vulnerability affects the function split_files/apply_delta_low_cpu_mem of the file fastchat/model/apply_delta.py. The manipulation leads to deserialization. An attack has to be approached locally.

A vulnerability, which was classified as critical, has been found in PCMan FTP Server 2.0.7. This issue affects some unknown processing of the component HELP Command Handler. The manipulation leads to buffer overflow. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used.