PHP is vulnerable to the Marvin Attack
Filter bypass in filtervar (FILTERVALIDATEURL)
In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUGON in >control parser
Fix a BUGON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing prerr and return -EINVAL instead.
Use after free issue in editcap could cause denial of service via crafted capture file
Memory handling issue in editcap could cause denial of service via crafted capture file
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2capchantimeout
The Linux kernel CVE team has assigned CVE-2024-27399 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051300-CVE-2024-27399-afa8@gregkh/T
An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.
Jinja is an extensible templating engine. The xmlattr filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, /, >, or =, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the xmlattr filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting values as user input continues to be safe. This vulnerability is fixed in 3.1.4.
In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things can fall through the cracks. Depending on the hardware model, URBs can have either bulk or interrupt type, and current version of vmk80xxfindusbendpoints() function does not take that fully into account. While this warning does not seem to be too harmful, at the very least it will crash systems with 'paniconwarn' set on them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the endpoint checking process with usbfindcommonendpoints() and ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usbsubmiturb+0xc4e/0x18c0 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usbstartwaiturb+0x113/0x520 drivers/usb/core/message.c:59 vmk80xxresetdevice drivers/comedi/drivers/vmk80xx.c:227 [inline] vmk80xxautoattach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818 comediautoconfig+0x238/0x380 drivers/comedi/drivers.c:1067 usbprobeinterface+0x5cd/0xb00 drivers/usb/core/driver.c:399 ...
Similar issue also found by Syzkaller:
drm/amdkfd: Fix memory leak in createprocess failure
In the Linux kernel, the following vulnerability has been resolved:
netfilter: flowtable: incorrect pppoe tuple
pppoe traffic reaching ingress path does not match the flowtable entry because the pppoe header is expected to be at the network header offset. This bug causes a mismatch in the flow table lookup, so pppoe packets enter the classical forwarding path.
In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree during disableunused
Doug reported [1] the following hung task:
INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: switchto+0xf4/0x1f4 schedule+0x418/0xb80 schedule+0x5c/0x10c rpmresume+0xe0/0x52c rpmresume+0x178/0x52c pmruntimeresume+0x58/0x98 clkpmruntimeget+0x30/0xb0 clkdisableunusedsubtree+0x58/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunusedsubtree+0x38/0x208 clkdisableunused+0x4c/0xe4 dooneinitcall+0xcc/0x2d8 doinitcalllevel+0xa4/0x148 doinitcalls+0x5c/0x9c dobasicsetup+0x24/0x30 kernelinitfreeable+0xec/0x164 kernelinit+0x28/0x120 retfromfork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: eventsunbound deferredprobeworkfunc Call trace: switchto+0xf4/0x1f4 schedule+0x418/0xb80 schedule+0x5c/0x10c schedulepreemptdisabled+0x2c/0x48 mutexlock+0x238/0x488 mutexlockslowpath+0x1c/0x28 mutexlock+0x50/0x74 clkpreparelock+0x7c/0x9c clkcorepreparelock+0x20/0x44 clkprepare+0x24/0x30 clkbulkprepare+0x40/0xb0 mdssruntimeresume+0x54/0x1c8 pmgenericruntimeresume+0x30/0x44 genpdruntimeresume+0x68/0x7c genpdruntimeresume+0x108/0x1f4 rpmcallback+0x84/0x144 rpmcallback+0x30/0x88 rpmresume+0x1f4/0x52c rpmresume+0x178/0x52c pmruntimeresume+0x58/0x98 deviceattach+0xe0/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deviceadd+0x644/0x814 mipidsideviceregisterfull+0xe4/0x170 devmmipidsideviceregisterfull+0x28/0x70 tisnbridgeprobe+0x1dc/0x2c0 auxiliarybusprobe+0x4c/0x94 reallyprobe+0xcc/0x2c8 driverprobedevice+0xa8/0x130 driverprobedevice+0x48/0x110 deviceattachdriver+0xa4/0xcc busforeachdrv+0x8c/0xd8 deviceattach+0xf8/0x170 deviceinitialprobe+0x1c/0x28 busprobedevice+0x3c/0x9c deferredprobeworkfunc+0x9c/0xd8 processonework+0x148/0x518 workerthread+0x138/0x350 kthread+0x138/0x1e0 retfromfork+0x10/0x20
The first thread is walking the clk tree and calling clkpmruntimeget() to power on devices required to read the clk hardware via struct clkops::isenabled(). This thread holds the clk preparelock, and is trying to runtime PM resume a device, when it finds that the device is in the process of resuming so the thread schedule()s away waiting for the device to finish resuming before continuing. The second thread is runtime PM resuming the same device, but the runtime resume callback is calling clkprepare(), trying to grab the preparelock waiting on the first thread.
This is a classic ABBA deadlock. To properly fix the deadlock, we must never runtime PM resume or suspend a device with the clk preparelock held. Actually doing that is near impossible today because the global preparelock would have to be dropped in the middle of the tree, the device runtime PM resumed/suspended, and then the preparelock grabbed again to ensure consistency of the clk tree topology. If anything changes with the clk tree in the meantime, we've lost and will need to start the operation all over again.
Luckily, most of the time we're simply incrementing or decrementing the runtime PM count on an active device, so we don't have the chance to schedule away with the preparelock held. Let's fix this immediate problem that can be ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
mm/memory-failure: fix deadlock when hugetlboptimizevmemmap is enabled
The Linux kernel CVE team has assigned CVE-2024-26987 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050143-CVE-2024-26987-507c@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
tun: limit printing rate when illegal packet received by tun dev
The Linux kernel CVE team has assigned CVE-2024-27013 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27013-2c26@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
The Linux kernel CVE team has assigned CVE-2024-27014 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T
Buffer Overflow vulnerability in Ffmpeg v.N113007-g8d24a28d06 allows a local attacker to execute arbitrary code via the libavfilter/avfshowwaves.c:722:24 in showwavesfilterframe
Summary
A XSS vulnerability exists on index pages for static file handling.
Details
When using web.static(..., showindex=True), the resulting index pages do not escape file names.
If users can upload files with arbitrary filenames to the static directory, the server is vulnerable to XSS attacks.
Workaround
We have always recommended using a reverse proxy server (e.g. nginx) for serving static files. Users following the recommendation are unaffected.
Other users can disable showindex if unable to upgrade.
-----
Patch: https://github.com/aio-libs/aiohttp/pull/8319/files
FFmpeg version n5.1 to n6.1 was discovered to contain an Off-by-one Error vulnerability in libavfilter/avfshowspectrum.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input.
Last updated 24 July 2024
Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit and other modes. This in particular means that they may set registers used to pass 32-bit-mode hypercall arguments to values outside of the range 32-bit code would be able to set them to.
When processing of hypercalls takes a considerable amount of time, the hypervisor may choose to invoke a hypercall continuation. Doing so involves putting (perhaps updated) hypercall arguments in respective registers. For guests not running in 64-bit mode this further involves a certain amount of translation of the values.
Unfortunately internal sanity checking of these translated values assumes high halves of registers to always be clear when invoking a hypercall. When this is found not to be the case, it triggers a consistency check in the hypervisor and causes a crash.
Chromium: CVE-2024-4059 Out of bounds read in V8 API
Impact
Undici cleared Authorization and Proxy-Authorization headers for fetch(), but did not clear them for undici.request().
Patches
This has been patched in https://github.com/nodejs/undici/commit/6805746680d27a5369d7fb67bc05f95a28247d75. Fixes has been released in v5.28.4 and v6.11.1.
Workarounds
use fetch() or disable maxRedirections.
References
Linzi Shang reported this.
https://hackerone.com/reports/2408074 https://github.com/nodejs/undici/security/advisories/GHSA-3787-6prv-h9w3
Accounts. The issue was addressed with improved checks.
Out-of-bounds Write vulnerability in Apache Commons Configuration.
Affected versions:
- Apache Commons Configuration 2.0 before 2.10.1
References:
https://www.cve.org/CVERecord?id=CVE-2024-29133 https://issues.apache.org/jira/browse/CONFIGURATION-841
Denial of Service via incomplete cleanup vulnerability in Apache Tomcat. It was possible for WebSocket clients to keep WebSocket connections open leading to increased resource consumption.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M16, from 10.1.0-M1 through 10.1.18, from 9.0.0-M1 through 9.0.85, from 8.5.0 through 8.5.98.
Older, EOL versions may also be affected.
Users are recommended to upgrade to version 11.0.0-M17, 10.1.19, 9.0.86 or 8.5.99 which fix the issue.
Last updated 24 July 2024
Impact An attacker could send a JWE containing compressed data that used large amounts of memory and CPU when decompressed by Decrypt or DecryptMulti. Those functions now return an error if the decompressed data would exceed 250kB or 10x the compressed size (whichever is larger). Thanks to Enze Wang@Alioth and Jianjun Chen@Zhongguancun Lab (@zer0yu and @chenjj) for reporting.
Patches The problem is fixed in the following packages and versions: - github.com/go-jose/go-jose/v4 version 4.0.1 - github.com/go-jose/go-jose/v3 version 3.0.3 - gopkg.in/go-jose/go-jose.v2 version 2.6.3
The problem will not be fixed in the following package because the package is archived: - gopkg.in/square/go-jose.v2
A vulnerability has been identified in the JSON Web Encryption (JWE) decryption interfaces, specifically related to the support for decompressing plaintext after its decryption. This allows an adversary to exploit specific scenarios where the compression ratio becomes exceptionally high. As a result, the length of the JWE token, which is determined by the compressed content's size, can land below application-defined limits. In such cases, other existing application level mechanisms for preventing resource exhaustion may be rendered ineffective.
Note that as per RFC 8725 compression of data SHOULD NOT be done before encryption, because such compressed data often reveals information about the plaintext. For this reason the v5.x major version of jose removed support for compressed payloads entirely and is therefore NOT affected by this advisory.
Impact
Under certain conditions it is possible to have the user's environment consume unreasonable amount of CPU time or memory during JWE Decryption operations.
Affected users
The impact is limited only to Node.js users utilizing the JWE decryption APIs to decrypt JWEs from untrusted sources.
You are NOT affected if any of the following applies to you
- Your code uses jose version v5.x where JWE Compression is not supported anymore - Your code runs in an environment other than Node.js (e.g. Deno, CF Workers), which is the only runtime where JWE Compression is implemented out of the box - Your code does not use the JWE decryption APIs - Your code only accepts JWEs produced by trusted sources
Patches
v2.0.7 and v4.15.5 releases limit the decompression routine to only allow decompressing up to 250 kB of plaintext. In v4.x it is possible to further adjust this limit via the inflateRaw decryption option implementation. In v2.x it is possible to further adjust this limit via the inflateRawSyncLimit decryption option.
Workarounds
If you cannot upgrade and do not want to support compressed JWEs you may detect and reject these tokens early by checking the token's protected header
js const { zip } = jose.decodeProtectedHeader(token) if (zip !== undefined) { throw new Error('JWE Compression is not supported') }
If you wish to continue supporting JWEs with compressed payloads in these legacy release lines you must upgrade (v1.x and v2.x to version v2.0.7, v3.x and v4.x to version v4.15.5) and review the limits put forth by the patched releases.
For more information If you have any questions or comments about this advisory please open a discussion in the project's repository
A malicious website may exfiltrate audio data cross-origin WebKit Bugzilla: 263795
A logic issue was addressed with improved state management. This issue is fixed in tvOS 17.4, macOS Sonoma 14.4, visionOS 1.1, iOS 17.4 and iPadOS 17.4, watchOS 10.4, iOS 16.7.6 and iPadOS 16.7.6, Safari 17.4. Processing maliciously crafted web content may prevent Content Security Policy from being enforced.