Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/ASPM: Fix deadlock when enabling ASPM<br /> <br /> A last minute revert in 6.7-final introduced a potential deadlock when<br /> enabling ASPM during probe of Qualcomm PCIe controllers as reported by<br /> lockdep:<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.7.0 #40 Not tainted<br /> --------------------------------------------<br /> kworker/u16:5/90 is trying to acquire lock:<br /> ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc<br /> <br /> but task is already holding lock:<br /> ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(pci_bus_sem);<br /> lock(pci_bus_sem);<br /> <br /> *** DEADLOCK ***<br /> <br /> Call trace:<br /> print_deadlock_bug+0x25c/0x348<br /> __lock_acquire+0x10a4/0x2064<br /> lock_acquire+0x1e8/0x318<br /> down_read+0x60/0x184<br /> pcie_aspm_pm_state_change+0x58/0xdc<br /> pci_set_full_power_state+0xa8/0x114<br /> pci_set_power_state+0xc4/0x120<br /> qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom]<br /> pci_walk_bus+0x64/0xbc<br /> qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]<br /> <br /> The deadlock can easily be reproduced on machines like the Lenovo ThinkPad<br /> X13s by adding a delay to increase the race window during asynchronous<br /> probe where another thread can take a write lock.<br /> <br /> Add a new pci_set_power_state_locked() and associated helper functions that<br /> can be called with the PCI bus semaphore held to avoid taking the read lock<br /> twice.

Certain WithSecure products allow a Denial of Service because the engine scanner can go into an infinite loop when processing an archive file. This affects WithSecure Client Security 15, WithSecure Server Security 15, WithSecure Email and Server Security 15, WithSecure Elements Endpoint Protection 17 and later, WithSecure Client Security for Mac 15, WithSecure Elements Endpoint Protection for Mac 17 and later, WithSecure Linux Security 64 12.0, WithSecure Linux Protection 12.0, and WithSecure Atlant 1.0.35-1.

orjson.loads in orjson before 3.9.15 does not limit recursion for deeply nested JSON documents.

In the Bentley ALIM Web application, certain configuration settings can cause exposure of a user&amp;#39;s ALIM session token when the user attempts to download files. This is fixed in Assetwise ALIM Web 23.00.04.04 and Assetwise Information Integrity Server 23.00.02.03.

rack-cors (aka Rack CORS Middleware) 2.0.1 has 0666 permissions for the .rb files.

Amazon Fire OS 7 before 7.6.6.9 and 8 before 8.1.0.3 allows Fire TV applications to establish local ADB (Android Debug Bridge) connections. NOTE: some third parties dispute whether this has security relevance, because an ADB connection is only possible after the (non-default) ADB Debugging option is enabled, and after the initiator of that specific connection attempt has been approved via a full-screen prompt.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/membarrier: reduce the ability to hammer on sys_membarrier<br /> <br /> On some systems, sys_membarrier can be very expensive, causing overall<br /> slowdowns for everything. So put a lock on the path in order to<br /> serialize the accesses to prevent the ability for this to be called at<br /> too high of a frequency and saturate the machine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> binder: signal epoll threads of self-work<br /> <br /> In (e)poll mode, threads often depend on I/O events to determine when<br /> data is ready for consumption. Within binder, a thread may initiate a<br /> command via BINDER_WRITE_READ without a read buffer and then make use<br /> of epoll_wait() or similar to consume any responses afterwards.<br /> <br /> It is then crucial that epoll threads are signaled via wakeup when they<br /> queue their own work. Otherwise, they risk waiting indefinitely for an<br /> event leaving their work unhandled. What is worse, subsequent commands<br /> won&amp;#39;t trigger a wakeup either as the thread has pending work.

pretix before 2024.1.1 mishandles file validation.

langchain_experimental (aka LangChain Experimental) in LangChain before 0.1.8 allows an attacker to bypass the CVE-2023-44467 fix and execute arbitrary code via the __import__, __subclasses__, __builtins__, __globals__, __getattribute__, __bases__, __mro__, or __base__ attribute in Python code. These are not prohibited by pal_chain/base.py.

Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP<br /> <br /> If the external phy working together with phy-omap-usb2 does not implement<br /> send_srp(), we may still attempt to call it. This can happen on an idle<br /> Ethernet gadget triggering a wakeup for example:<br /> <br /> configfs-gadget.g1 gadget.0: ECM Suspend<br /> configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup<br /> ...<br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 00000000 when execute<br /> ...<br /> PC is at 0x0<br /> LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]<br /> ...<br /> musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]<br /> usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]<br /> eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c<br /> dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4<br /> sch_direct_xmit from __dev_queue_xmit+0x334/0xd88<br /> __dev_queue_xmit from arp_solicit+0xf0/0x268<br /> arp_solicit from neigh_probe+0x54/0x7c<br /> neigh_probe from __neigh_event_send+0x22c/0x47c<br /> __neigh_event_send from neigh_resolve_output+0x14c/0x1c0<br /> neigh_resolve_output from ip_finish_output2+0x1c8/0x628<br /> ip_finish_output2 from ip_send_skb+0x40/0xd8<br /> ip_send_skb from udp_send_skb+0x124/0x340<br /> udp_send_skb from udp_sendmsg+0x780/0x984<br /> udp_sendmsg from __sys_sendto+0xd8/0x158<br /> __sys_sendto from ret_fast_syscall+0x0/0x58<br /> <br /> Let&amp;#39;s fix the issue by checking for send_srp() and set_vbus() before<br /> calling them. For USB peripheral only cases these both could be NULL.