| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
Reapply "drm/qxl: simplify qxl_fence_wait"
This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.
Stephen Rostedt reports:
"I went to run my tests on my VMs and the tests hung on boot up.
Unfortunately, the most I ever got out was:
[ 93.607888] Testing event system initcall: OK
[ 93.667730] Running tests on all trace events:
[ 93.669757] Testing all events: OK
[ 95.631064] ------------[ cut here ]------------
Timed out after 60 seconds"
and further debugging points to a possible circular locking dependency
between the console_owner locking and the worker pool locking.
Reverting the commit allows Steve's VM to boot to completion again.
[ This may obviously result in the "[TTM] Buffer eviction failed"
messages again, which was the reason for that original revert. But at
this point this seems preferable to a non-booting system... ] |
| In the Linux kernel, the following vulnerability has been resolved:
ceph: fix deadlock or deadcode of misusing dget()
The lock order is incorrect between denty and its parent, we should
always make sure that the parent get the lock first.
But since this deadcode is never used and the parent dir will always
be set from the callers, let's just remove it. |
| In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246750467 |
| In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246749936 |
| In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246749702 |
| In multiple locations, there is a possible way to trigger a persistent reboot loop due to improper input validation. This could lead to local denial of service with User execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-246749764 |
| copyparty, a portable file server, has a DOM-based cross-site scripting vulnerability in versions prior to 1.16.15. The vulnerability is considered low-risk. By handing someone a maliciously-named file, and then tricking them into dragging the file into copyparty's Web-UI, an attacker could execute arbitrary javascript with the same privileges as that user. For example, this could give unintended read-access to files owned by that user. The bug is triggered by the drag-drop action itself; it is not necessary to actually initiate the upload. The file must be empty (zero bytes). Note that, as a general-purpose webserver, it is intentionally possible to upload HTML-files with arbitrary javascript in `<script>` tags, which will execute when the file is opened. The difference is that this vulnerability would trigger execution of javascript during the act of uploading, and not when the uploaded file was opened. Version 1.16.15 contains a fix. |
| In the Linux kernel, the following vulnerability has been resolved:
iomap: avoid avoid truncating 64-bit offset to 32 bits
on 32-bit kernels, iomap_write_delalloc_scan() was inadvertently using a
32-bit position due to folio_next_index() returning an unsigned long.
This could lead to an infinite loop when writing to an xfs filesystem. |
| Windows Security Account Manager (SAM) Denial of Service Vulnerability |
| In the Linux kernel, the following vulnerability has been resolved:
openvswitch: fix lockup on tx to unregistering netdev with carrier
Commit in a fixes tag attempted to fix the issue in the following
sequence of calls:
do_output
-> ovs_vport_send
-> dev_queue_xmit
-> __dev_queue_xmit
-> netdev_core_pick_tx
-> skb_tx_hash
When device is unregistering, the 'dev->real_num_tx_queues' goes to
zero and the 'while (unlikely(hash >= qcount))' loop inside the
'skb_tx_hash' becomes infinite, locking up the core forever.
But unfortunately, checking just the carrier status is not enough to
fix the issue, because some devices may still be in unregistering
state while reporting carrier status OK.
One example of such device is a net/dummy. It sets carrier ON
on start, but it doesn't implement .ndo_stop to set the carrier off.
And it makes sense, because dummy doesn't really have a carrier.
Therefore, while this device is unregistering, it's still easy to hit
the infinite loop in the skb_tx_hash() from the OVS datapath. There
might be other drivers that do the same, but dummy by itself is
important for the OVS ecosystem, because it is frequently used as a
packet sink for tcpdump while debugging OVS deployments. And when the
issue is hit, the only way to recover is to reboot.
Fix that by also checking if the device is running. The running
state is handled by the net core during unregistering, so it covers
unregistering case better, and we don't really need to send packets
to devices that are not running anyway.
While only checking the running state might be enough, the carrier
check is preserved. The running and the carrier states seem disjoined
throughout the code and different drivers. And other core functions
like __dev_direct_xmit() check both before attempting to transmit
a packet. So, it seems safer to check both flags in OVS as well. |
| This vulnerability allows remote attackers to create a denial-of-service condition on affected installations of Unified Automation OPC UA C++ Demo Server 1.7.6-537 [with vendor rollup]. Authentication is not required to exploit this vulnerability. The specific flaw exists within the handling of certificates. A crafted certificate can force the server into an infinite loop. An attacker can leverage this vulnerability to create a denial-of-service condition on the system. Was ZDI-CAN-17203. |
| In PHP 8.3.* before 8.3.5, function mb_encode_mimeheader() runs endlessly for some inputs that contain long strings of non-space characters followed by a space. This could lead to a potential DoS attack if a hostile user sends data to an application that uses this function. |
| Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.3 through 1.25.0.
Users are recommended to upgrade to version 1.26.0 which fixes the issue. |
| EDK2's Network Package is susceptible to an infinite lop vulnerability when parsing a PadN option in the Destination Options header of IPv6. This
vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Availability. |
| EDK2's Network Package is susceptible to an infinite loop vulnerability when parsing unknown options in the Destination Options header of IPv6. This
vulnerability can be exploited by an attacker to gain unauthorized
access and potentially lead to a loss of Availability. |
| RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature. |
| aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. In affected versions an attacker can send a specially crafted POST (multipart/form-data) request. When the aiohttp server processes it, the server will enter an infinite loop and be unable to process any further requests. An attacker can stop the application from serving requests after sending a single request. This issue has been addressed in version 3.9.4. Users are advised to upgrade. Users unable to upgrade may manually apply a patch to their systems. Please see the linked GHSA for instructions. |
| A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an infinite loop. |
| The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set. |
| Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache NimBLE.
Specially crafted GATT operation can cause infinite loop in GATT server leading to denial of service in Bluetooth stack or device.
This issue affects Apache NimBLE: through 1.6.0.
Users are recommended to upgrade to version 1.7.0, which fixes the issue. |
