| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Buffer over-read in Windows USB Driver allows an authorized attacker to disclose information locally. |
| Double free in Windows Shell allows an unauthorized attacker to execute code over a network. |
| Heap-based buffer overflow in Windows Storage Spaces Controller allows an authorized attacker to elevate privileges locally. |
| In the Linux kernel, the following vulnerability has been resolved:
net: skbuff: preserve shared-frag marker during coalescing
skb_try_coalesce() can attach paged frags from @from to @to. If @from
has SKBFL_SHARED_FRAG set, the resulting @to skb can contain the same
externally-owned or page-cache-backed frags, but the shared-frag marker
is currently lost.
That breaks the invariant relied on by later in-place writers. In
particular, ESP input checks skb_has_shared_frag() before deciding
whether an uncloned nonlinear skb can skip skb_cow_data(). If TCP
receive coalescing has moved shared frags into an unmarked skb, ESP can
see skb_has_shared_frag() as false and decrypt in place over page-cache
backed frags.
Propagate SKBFL_SHARED_FRAG when skb_try_coalesce() transfers paged
frags. The tailroom copy path does not need the marker because it copies
bytes into @to's linear data rather than transferring frag descriptors. |
| When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size.
Impact:
An authenticated principal with Write on a topic can crash broker request-handler threads (reached when a batch's codec differs from the topic's compression.type and records are re-encoded) and any consumer that fetches the record, denying service. On brokers started with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the broker JVM. More seriously, a crafted record is accepted at ingest and written to disk; when the log-cleaner later reads it on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner thread, which is not restarted. With the default of a single cleaner thread, log compaction then stops for the entire broker, including the internal __consumer_offsets and __transaction_state topics, and the condition persists across restarts until the offending record is removed. The impact is availability only; no data is disclosed or altered.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is not sufficient: for backward compatibility this configuration defaults to an effectively unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a value at or slightly above the largest legitimate decompressed record your applications produce, and comfortably below the broker heap divided by the number of request-handler and cleaner threads. Until you can upgrade and configure the limit, restrict Write access to trusted producers; quotas and max.message.bytes do not mitigate this issue.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record's declared decompressed body size against max.decompressed.message.bytes before allocating, on the produce-validation, log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with InvalidRecordException. Operators must set this configuration to a bounded value to be protected, as its default is effectively unlimited. |
| Heap-based buffer overflow in Windows Fax and Scan Service allows an authorized attacker to elevate privileges locally. |
| Integer overflow or wraparound in Microsoft Office Outlook allows an unauthorized attacker to execute code over a network. |
| Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to execute code locally. |
| Stack-based buffer overflow in Windows Win32K allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows SMB Client allows an unauthorized attacker to elevate privileges over a network. |
| Out-of-bounds read in Windows Internet Key Exchange (IKE) Protocol allows an unauthorized attacker to deny service over a network. |
| Heap-based buffer overflow in Windows USB Driver allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows NTFS allows an authorized attacker to execute code locally. |
| Integer overflow or wraparound in Windows Background Intelligent Transfer Service (BITS) allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows Sensor Data Service allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows USB Driver allows an authorized attacker to elevate privileges locally. |
| Heap-based buffer overflow in Windows DWM Core Library allows an authorized attacker to elevate privileges locally. |
| Out-of-bounds read in Windows Key Storage Provider allows an authorized attacker to disclose information locally. |
| Use after free in Windows Background Intelligent Transfer Service (BITS) allows an unauthorized attacker to execute code over a network. |
| Out-of-bounds read in Windows Kernel-Mode Drivers allows an authorized attacker to elevate privileges locally. |
