Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: storage: Fix memory leak in USB bulk transport<br /> <br /> A kernel memory leak was identified by the &amp;#39;ioctl_sg01&amp;#39; test from Linux<br /> Test Project (LTP). The following bytes were mainly observed: 0x53425355.<br /> <br /> When USB storage devices incorrectly skip the data phase with status data,<br /> the code extracts/validates the CSW from the sg buffer, but fails to clear<br /> it afterwards. This leaves status protocol data in srb&amp;#39;s transfer buffer,<br /> such as the US_BULK_CS_SIGN &amp;#39;USBS&amp;#39; signature observed here. Thus, this can<br /> lead to USB protocols leaks to user space through SCSI generic (/dev/sg*)<br /> interfaces, such as the one seen here when the LTP test requested 512 KiB.<br /> <br /> Fix the leak by zeroing the CSW data in srb&amp;#39;s transfer buffer immediately<br /> after the validation of devices that skip data phase.<br /> <br /> Note: Differently from CVE-2018-1000204, which fixed a big leak by zero-<br /> ing pages at allocation time, this leak occurs after allocation, when USB<br /> protocol data is written to already-allocated sg pages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_eem: Fix memory leak in eem_unwrap<br /> <br /> The existing code did not handle the failure case of usb_ep_queue in the<br /> command path, potentially leading to memory leaks.<br /> <br /> Improve error handling to free all allocated resources on usb_ep_queue<br /> failure. This patch continues to use goto logic for error handling, as the<br /> existing error handling is complex and not easily adaptable to auto-cleanup<br /> helpers.<br /> <br /> kmemleak results:<br /> unreferenced object 0xffffff895a512300 (size 240):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> kmem_cache_alloc+0x1b4/0x358<br /> skb_clone+0x90/0xd8<br /> eem_unwrap+0x1cc/0x36c<br /> unreferenced object 0xffffff8a157f4000 (size 256):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> __kmem_cache_alloc_node+0x1b4/0x2dc<br /> kmalloc_trace+0x48/0x140<br /> dwc3_gadget_ep_alloc_request+0x58/0x11c<br /> usb_ep_alloc_request+0x40/0xe4<br /> eem_unwrap+0x204/0x36c<br /> unreferenced object 0xffffff8aadbaac00 (size 128):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> __kmem_cache_alloc_node+0x1b4/0x2dc<br /> __kmalloc+0x64/0x1a8<br /> eem_unwrap+0x218/0x36c<br /> unreferenced object 0xffffff89ccef3500 (size 64):<br /> backtrace:<br /> slab_post_alloc_hook+0xbc/0x3a4<br /> __kmem_cache_alloc_node+0x1b4/0x2dc<br /> kmalloc_trace+0x48/0x140<br /> eem_unwrap+0x238/0x36c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> most: usb: fix double free on late probe failure<br /> <br /> The MOST subsystem has a non-standard registration function which frees<br /> the interface on registration failures and on deregistration.<br /> <br /> This unsurprisingly leads to bugs in the MOST drivers, and a couple of<br /> recent changes turned a reference underflow and use-after-free in the<br /> USB driver into several double free and a use-after-free on late probe<br /> failures.

In JetBrains IntelliJ IDEA before 2025.3 missing confirmation allowed opening of untrusted remote projects over SSH

In JetBrains TeamCity before 2025.11.1 reflected XSS was possible on the storage settings page

In JetBrains TeamCity before 2025.11.1 excessive privileges were possible due to storing GitHub personal access token instead of an installation token

In JetBrains TeamCity before 2025.11 a DOM-based XSS was possible on the OAuth connections tab

In JetBrains TeamCity before 2025.11 reflected XSS was possible on VCS Root setup

In JetBrains TeamCity before 2025.11 port enumeration was possible via the Perforce connection test

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: udc: fix use-after-free in usb_gadget_state_work<br /> <br /> A race condition during gadget teardown can lead to a use-after-free<br /> in usb_gadget_state_work(), as reported by KASAN:<br /> <br /> BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0<br /> Workqueue: events usb_gadget_state_work<br /> <br /> The fundamental race occurs because a concurrent event (e.g., an<br /> interrupt) can call usb_gadget_set_state() and schedule gadget-&gt;work<br /> at any time during the cleanup process in usb_del_gadget().<br /> <br /> Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue after<br /> device removal") attempted to fix this by moving flush_work() to after<br /> device_del(). However, this does not fully solve the race, as a new<br /> work item can still be scheduled *after* flush_work() completes but<br /> before the gadget&amp;#39;s memory is freed, leading to the same use-after-free.<br /> <br /> This patch fixes the race condition robustly by introducing a &amp;#39;teardown&amp;#39;<br /> flag and a &amp;#39;state_lock&amp;#39; spinlock to the usb_gadget struct. The flag is<br /> set during cleanup in usb_del_gadget() *before* calling flush_work() to<br /> prevent any new work from being scheduled once cleanup has commenced.<br /> The scheduling site, usb_gadget_set_state(), now checks this flag under<br /> the lock before queueing the work, thus safely closing the race window.

In JetBrains TeamCity before 2025.11 stored XSS was possible on agentpushInstall page

In JetBrains TeamCity before 2025.11 maven embedder allowed loading extensions via project configuration