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.

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.

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.

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 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.

Suricata is a network Intrusion Detection System, Intrusion Prevention System and Network Security Monitoring engine. Prior to 7.0.3, the rules inspecting HTTP2 headers can get bypassed by crafted traffic. The vulnerability has been patched in 7.0.3.

c-ares is a C library for asynchronous DNS requests. aresreadline() is used to parse local configuration files such as /etc/resolv.conf, /etc/nsswitch.conf, the HOSTALIASES file, and if using a c-ares version prior to 1.27.0, the /etc/hosts file. If any of these configuration files has an embedded NULL character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.

In wpasupplicant, a flaw was discovered in the implementation of PEAP, which allows an attacker to skip the second phase of authentication when the target device has not been properly configured to verify the authentication server. Note that PEAP is the most common authentication method for Enterprise networks. By skipping Phase-2 authentication, it’s much easier for an attacker to create a rogue clone of a trusted WiFi network and trick the victim into connecting, all without knowing their password.

Typical Attack Prerequisites: - The attacker needs to know the SSID of the target Enterprise WPA2/3 network - The attacker must be within range of their victim, who can be located anywhere, i.e. they don’t need to be in range of the network being impersonated during the attack - wpasupplicant must be configured to not verify the authentication server’s TLS certificate

It is trivial to harvest SSIDs from around office buildings or to advertise popular Enterprise network names such as eduroam, Vodafone Homespot, TelenetWiFree or Unitymedia WifiSpot for example, and simply wait for an unsuspecting victim to connect. The misconfiguration of wpasupplicant is unfortunately a known issue on many systems. Proper configuration is a manual process, whose confusing and tedious nature prompts many users to skip it.

References: https://www.top10vpn.com/research/wifi-vulnerabilities/ https://w1.fi/cgit/hostap/commit/?id=8e6485a1bcb0baff

MSA-24-0003: H5P attempts report did not respect activity group settings

Description: Separate Groups mode restrictions were not honoured in the H5P attempts report, which would display users from other groups. By default this only provided additional access to non-editing teachers. Issue summary: H5P attempts report did not respect activity group settings Severity/Risk: Minor Versions affected: 4.3 to 4.3.2, 4.2 to 4.2.5, 4.1 to 4.1.8 and earlier unsupported versions Versions fixed: 4.3.3, 4.2.6 and 4.1.9 Reported by: Leon Stringer Issue no.: MDL-80501 CVE identifier: Pending Changes (master): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-80501

MSA-24-0002: Forum search accepted random parameters in its URL

Description: The URL parameters accepted by forum search were not limited to the allowed parameters. Issue summary: Forum search accepted random parameters in its URL Severity/Risk: Minor Versions affected: 4.3 to 4.3.2, 4.2 to 4.2.5, 4.1 to 4.1.8 and earlier unsupported versions Versions fixed: 4.3.3, 4.2.6 and 4.1.9 Reported by: Piotr Widak Issue no.: MDL-69774 CVE identifier: Pending Changes (master): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-69774

Insufficient checks in a web service made it possible to add comments to the comments block on another user's dashboard when it was not otherwise available (e.g., on their profile page).

MSA-24-0004: Forum export did not respect activity group settings

Description: Separate Groups mode restrictions were not honoured when performing a forum export, which would export forum data for all groups. By default this only provided additional access to non-editing teachers. Issue summary: Forum export did not respect activity group settings Severity/Risk: Minor Versions affected: 4.3 to 4.3.2, 4.2 to 4.2.5, 4.1 to 4.1.8 and earlier unsupported versions Versions fixed: 4.3.3, 4.2.6 and 4.1.9 Reported by: Leon Stringer Issue no.: MDL-80504 CVE identifier: Pending Changes (master): http://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-80504

A flaw in the Linux Kernel found in the Open vSwitch Kernel module.

The Netlink copy code in the ovs kernel module attempts to make an in-kernel copy of the actions required. That means that when recursive operations, like sample(), clone(), decttl(), etc include additional actions, the code pushes a new stack frame and recursively calls into the code block.

Unfortunately, OVS module doesn't validate the stack depth, and will push too many frames causing a stack overflow which can lead to crash.

Reference: https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/

An information disclosure flaw was found in ansible-core due to a failure to respect the ANSIBLENOLOG configuration in some scenarios. It was discovered that information is still included in the output in certain tasks, such as loop items. Depending on the task, this issue may include sensitive information, such as decrypted secret values.

Impact Denial of Service, Applications that allow the use of the PBKDF2 algorithm.

Patches A patch is available that sets the maximum number of default rounds.

Workarounds Applications that do not need to use PBKDF2 should simply specify the algorithms use and exclude it from the list. Applications that need to use the algorithm should upgrade to the new version that allows to set a maximum rounds number.

Acknowledgement The issues was reported by Jingcheng Yang and Jianjun Chen from Sichuan University and Zhongguancun Lab

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

A null pointer dereference vulnerability was found in dpllpinparentpinset() in drivers/dpll/dpllnetlink.c in Digital Phase Locked Loop (DPLL) subsystem in the Linux kernel, which could be exploited to trigger denial of service.

Refer: https://lore.kernel.org/netdev/20231211083758.1082853-1-jiri@resnulli.us/

A null pointer dereference vulnerability was found in nftdynsetinit() in net/netfilter/nftdynset.c in nftables in the Linux kernel. This issue may allow a local attacker with CAPNETADMIN user privilege to trigger a denial of service.