HTTP/2 Rapid reset attack The HTTP/2 protocol allows clients to indicate to the server that a previous stream should be canceled by sending a RSTSTREAM frame. The protocol does not require the client and server to coordinate the cancellation in any way, the client may do it unilaterally. The client may also assume that the cancellation will take effect immediately when the server receives the RSTSTREAM frame, before any other data from that TCP connection is processed.

Abuse of this feature is called a Rapid Reset attack because it relies on the ability for an endpoint to send a RSTSTREAM frame immediately after sending a request frame, which makes the other endpoint start working and then rapidly resets the request. The request is canceled, but leaves the HTTP/2 connection open.

The HTTP/2 Rapid Reset attack built on this capability is simple: The client opens a large number of streams at once as in the standard HTTP/2 attack, but rather than waiting for a response to each request stream from the server or proxy, the client cancels each request immediately.

The ability to reset streams immediately allows each connection to have an indefinite number of requests in flight. By explicitly canceling the requests, the attacker never exceeds the limit on the number of concurrent open streams. The number of in-flight requests is no longer dependent on the round-trip time (RTT), but only on the available network bandwidth.

In a typical HTTP/2 server implementation, the server will still have to do significant amounts of work for canceled requests, such as allocating new stream data structures, parsing the query and doing header decompression, and mapping the URL to a resource. For reverse proxy implementations, the request may be proxied to the backend server before the RSTSTREAM frame is processed. The client on the other hand paid almost no costs for sending the requests. This creates an exploitable cost asymmetry between the server and the client.

Multiple software artifacts implementing HTTP/2 are affected. This advisory was originally ingested from the swift-nio-http2 repo advisory and their original conent follows.

swift-nio-http2 specific advisory swift-nio-http2 is vulnerable to a denial-of-service vulnerability in which a malicious client can create and then reset a large number of HTTP/2 streams in a short period of time. This causes swift-nio-http2 to commit to a large amount of expensive work which it then throws away, including creating entirely new Channels to serve the traffic. This can easily overwhelm an EventLoop and prevent it from making forward progress.

swift-nio-http2 1.28 contains a remediation for this issue that applies reset counter using a sliding window. This constrains the number of stream resets that may occur in a given window of time. Clients violating this limit will have their connections torn down. This allows clients to continue to cancel streams for legitimate reasons, while constraining malicious actors.

A flaw was found in rsvpchange(). The root cause is an slab-out-of-bound access, but since the offset to the original pointer is an unsign int fully controlled by users, the behavior is usually a wild pointer access.

A flaw was found in ipv4senddestunreach() due to NULL pointer derefence due to a missing edge-case check.

An array indexing vulnerability was found in the netfilter subsystem of the Linux kernel. A missing macro could lead to a miscalculation of the h->nets array offset, providing attackers with the primitive to arbitrarily increment/decrement a memory buffer out-of-bound. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.

A flaw was found in the XFRM subsystem in the Linux kernel. The specific flaw exists within the processing of state filters, which can result in a read past the end of an allocated buffer. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, potentially leading to an information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The sctpmtcheck did not validate the flagcount field. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The xtu32 module did not validate the fields in the xtu32 structure. This flaw allows a local privileged attacker to trigger an out-of-bounds read by setting the size fields with a value beyond the array boundaries, leading to a crash or information disclosure.

A flaw was found in the Netfilter subsystem in the Linux kernel. The nfnlosfaddcallback function did not validate the user mode controlled optnum field. This flaw allows a local privileged (CAPNETADMIN) attacker to trigger an out-of-bounds read, leading to a crash or information disclosure.

In the Linux kernel through 6.3.1, a use-after-free in Netfilter nftables when processing batch requests can be abused to perform arbitrary read and write operations on kernel memory. Unprivileged local users can obtain root privileges. This occurs because anonymous sets are mishandled.

An out-of-bounds read issue was found in the NVMe-oF/TCP subsystem in the Linux kernel. A remote attacker could send a crafted TCP packet triggering a heap-based buffer overflow that results in kmalloc data to be printed (and potentially leaked) to the kernel ring buffer (dmesg).

Upstream refs: https://lore.kernel.org/linux-nvme/b58a2dc6-cc8f-4d19-9efe-e1d5b4505efc@nvidia.com/T/ https://lore.kernel.org/linux-nvme/CAK5usQvxAyC3LJ4OnqerS1P0JpbfFr9uRZmq6Jb4QhaB7AQCoQ@mail.gmail.com/T/

A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.

A use-after-free vulnerability was found in drivers/nvme/target/tcp.c in nvmettcpfreecrypto due to a logical bug in the NVMe-oF/TCP subsystem in the Linux kernel. In this flaw, a malicious user can cause a UAF and a double free, which may lead to RCE (may also lead to an LPE in case the attacker already has local privileges).

Reference: https://lore.kernel.org/linux-nvme/20231002105428.226515-1-sagi@grimberg.me/

A flaw has been identified in glibc. In an uncommon situation, the gaihinet function may use memory that has been freed, resulting in an application crash. This issue is only exploitable when the getaddrinfo function is called and the hosts database in /etc/nsswitch.conf is configured with SUCCESS=continue or SUCCESS=merge.

A flaw was found in the GNU C Library. A recent fix for CVE-2023-4806 introduced the potential for a memory leak, which may result in an application crash.

A buffer overflow was discovered in the GNU C Library's dynamic loader ld.so while processing the GLIBCTUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBCTUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.

A flaw was found in the exFAT driver of the Linux kernel. The vulnerability exists in the implementation of the file name reconstruction function, which is responsible for reading file name entries from a directory index and merging file name parts belonging to one file into a single long file name. Since the file name characters are copied into a stack variable, a local privileged attacker could use this flaw to overflow the kernel stack.

A flaw in the Linux Kernel found. Improper element removal in function nftpipaporemove when insert an element without a NFTSETEXTKEYEND that can lead to use-after-free.

Reference: https://patchwork.ozlabs.org/project/netfilter-devel/patch/20230719190824.21196-1-fw@strlen.de/

========== 1. Null-ptr-deref in xfrmupdateaeparams() ==========

[require privilege]: CAPNETADMIN

[effects]: local DoS

[crash stack]: [ 47.933119] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 47.933119] #PF: supervisor write access in kernel mode [ 47.933119] #PF: errorcode(0x0002) - not-present page [ 47.933119] PGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0 [ 47.933119] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI [ 47.933119] CPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8 [ 47.933119] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4 [ 47.933119] RIP: 0010:memcpyorig+0xad/0x140 [ 47.933119] Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c [ 47.933119] RSP: 0018:ffff888008f57658 EFLAGS: 00000202 [ 47.933119] RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 [ 47.933119] RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 [ 47.933119] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 47.933119] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 [ 47.933119] R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 [ 47.933119] FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 [ 47.933119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.933119] CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 [ 47.933119] Call Trace: [ 47.933119] <TASK> [ 47.933119] ? die+0x1f/0x70 [ 47.933119] ? pagefaultoops+0x1e8/0x500 [ 47.933119] ? pfxisprefetch.constprop.0+0x10/0x10 [ 47.933119] ? pfxpagefaultoops+0x10/0x10 [ 47.933119] ? rawspinunlockirqrestore+0x11/0x40 [ 47.933119] ? fixupexception+0x36/0x460 [ 47.933119] ? rawspinunlockirqrestore+0x11/0x40 [ 47.933119] ? excpagefault+0x5e/0xc0 [ 47.933119] ? asmexcpagefault+0x26/0x30 [ 47.933119] ? xfrmupdateaeparams+0xd1/0x260 [ 47.933119] ? memcpyorig+0xad/0x140 [ 47.933119] ? pfxrawspinlockbh+0x10/0x10 [ 47.933119] xfrmupdateaeparams+0xe7/0x260 [ 47.933119] xfrmnewae+0x298/0x4e0 [ 47.933119] ? pfxxfrmnewae+0x10/0x10 [ 47.933119] xfrmuserrcvmsg+0x25a/0x410 [ 47.933119] ? pfxxfrmuserrcvmsg+0x10/0x10 [ 47.933119] ? allocskb+0xcf/0x210 [ 47.933119] ? stacktracesave+0x90/0xd0 [ 47.933119] ? filterirqstacks+0x1c/0x70 [ 47.933119] ? stackdepotsave+0x39/0x4e0 [ 47.933119] ? kasanslabfree+0x10a/0x190 [ 47.933119] ? kmemcachefree+0x9c/0x340 [ 47.933119] ? netlinkrecvmsg+0x23c/0x660 [ 47.933119] ? sockrecvmsg+0xeb/0xf0 [ 47.933119] ? sysrecvfrom+0x13c/0x1f0 [ 47.933119] ? x64sysrecvfrom+0x71/0x90 [ 47.933119] ? dosyscall64+0x3f/0x90 [ 47.933119] ? entrySYSCALL64afterhwframe+0x72/0xdc [ 47.933119] ? copyout+0x3e/0x50 [ 47.933119] netlinkrcvskb+0xd6/0x210 [ 47.933119] ? pfxxfrmuserrcvmsg+0x10/0x10 [ 47.933119] ? pfxnetlinkrcvskb+0x10/0x10 [ 47.933119] ? pfxsockhasperm+0x10/0x10 [ 47.933119] ? mutexlock+0x8d/0xe0 [ 47.933119] ? pfxmutexlock+0x10/0x10 [ 47.933119] xfrmnetlinkrcv+0x44/0x50 [ 47.933119] netlinkunicast+0x36f/0x4c0 [ 47.933119] ? pfxnetlinkunicast+0x10/0x10 [ 47.933119] ? netlinkrecvmsg+0x500/0x660 [ 47.933119] netlinksendmsg+0x3b7/0x700 [ 47.933119] ? pfxnetlinksendmsg+0x10/0x10 [ 47.933119] ? updateloadavg+0x591/0xab0 [ 47.933119] ? pfxnetlinksendmsg+0x10/0x10 [ 47.933119] socksendmsg+0xde/0xe0 [ 47.933119] syssendto+0x18d/0x230 [ 47.933119] ? pfxsyssendto+0x10/0x10 [ 47.933119] ? rbinsertcolor+0x1c0/0x280 [ 47.933119] ? timerqueueadd+0x128/0x150 [ 47.933119] ? ktimeget+0x49/0xb0 [ 47.933119] ? pfxnativeapicmemwrite+0x10/0x10 [ 47.933119] ? lapicnextevent+0x35/0x40 [ 47.933119] ? clockeventsprogramevent+0xdf/0x140 [ 47.933119] ? hrtimerinterrupt+0x321/0x360 [ 47.933119] x64syssendto+0x71/0x90 [ 47.933119] dosyscall64+0x3f/0x90 [ 47.933119] entrySYSCALL64afterhwframe+0x72/0xdc [ 47.933119] RIP: 0033:0x44b8aa [ 47.933119] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 9 [ 47.933119] RSP: 002b:00007fff7ded8258 EFLAGS: 00000246 ORIGRAX: 000000000000002c [ 47.933119] RAX: ffffffffffffffda RBX: 00007fff7ded9688 RCX: 000000000044b8aa [ 47.933119] RDX: 00000000000002a8 RSI: 00007fff7ded8480 RDI: 0000000000000003 [ 47.933119] RBP: 00007fff7ded82c0 R08: 00007fff7ded829c R09: 000000000000000c [ 47.933119] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 47.933119] R13: 00007fff7ded9678 R14: 00000000004c37d0 R15: 0000000000000001 [ 47.933119] </TASK> [ 47.933119] Modules linked in: [ 47.933119] CR2: 0000000000000000 [ 47.933119] ---[ end trace 0000000000000000 ]--- [ 47.933119] RIP: 0010:memcpyorig+0xad/0x140 [ 47.933119] Code: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c [ 47.933119] RSP: 0018:ffff888008f57658 EFLAGS: 00000202 [ 47.933119] RAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571 [ 47.933119] RDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000 [ 47.933119] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 [ 47.933119] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818 [ 47.933119] R13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000 [ 47.933119] FS: 00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000 [ 47.933119] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 47.933119] CR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0 [ 47.933119] Kernel panic - not syncing: Fatal exception in interrupt [ 47.933119] Kernel Offset: disabled [ 47.933119] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

[buggy commit]: d8647b79c3b7 ("xfrm: Add user interface for esn and big anti-replay windows")

[root cause]: x->replayesn and x->preplayesn should be allocated at xfrmallocreplaystateesn(...) in xfrmstateconstruct(..), and then the xfrmupdateaeparams(...) is okay to update them. However, the current implementation allows a malicious user to directly dereference the pointer and crash the kernel like above.

[PoC code]: see attachment poc1.c. I have tested it in ubuntu 22.04 and latest Linux with QEMU.

[suggest fix]: Add NULL check in xfrmupdateaeparams() like below:

@@ -628,7 +628,7 @@ static void xfrmupdateaeparams(struct xfrmstate x, struct nlattr attrs, struct nlattr rt = attrs[XFRMAREPLAYTHRESH]; struct nlattr mt = attrs[XFRMAMTIMERTHRESH];

- if (re) { + if (re && x->replayesn && x->preplayesn) { struct xfrmreplaystateesn replayesn;

========== 2. OOB read of XFRMAMTIMERTHRESH nlattr ==========

[require privilege]: CAPNETADMIN

[effects]: information leak

[crash stack]: Interesting enough as this OOB read will not be detected by KASan (perhaps why this bug is not detected by the fuzzer), see the details below.

[buggy commit]: 4e484b3e969b ("xfrm: rate limit SA mapping change message to user space")

[root cause]: The mentioned commit above added one additional attribute named XFRMAMTIMERTHRESH and described its type at compatpolicy (net/xfrm/xfrmcompat.c). However, the author forgot to also describe it at xfrmapolicy (net/xfrm/xfrmuser.c). Hence, this suppose NLAU32 (4 bytes) value can be faked as empty (0 bytes) by a malicious user, which lead to 4 bytes overflow read when parsing nlattrs.

The overall buffer skb is created at netlinksendmsg(...). According to the code, it will add another 0x140 skbsharedinfo data behind the skb data so this OOB will not be detected by KASan.

To exploit this (see PoC part), one malicious user can spray the SLUB objects and then leverage this 4 bytes OOB read to leak the heap data into x->mappingmaxage (see xfrmupdateaeparams(...)), and leak it to userspace via copytouserstateextra(...).

[PoC code]: see attachment poc2.c. I have tested it in latest Linux with QEMU. (no effects in ubuntu thanks to CONFIGINITONALLOCDEFAULTON)

[suggest fix]: Just add the type description like below

@@ -3035,6 +3035,7 @@ const struct nlapolicy xfrmapolicy[XFRMAMAX+1] = { [XFRMASETMARK] = { .type = NLAU32 }, [XFRMASETMARKMASK] = { .type = NLAU32 }, [XFRMAIFID] = { .type = NLAU32 }, + [XFRMAMTIMERTHRESH] = { .type = NLAU32 }, };

Buffer overflow vulnerabilities in functions pnggetPLTE/pngsetPLTE, allowing remote attackers to cause DoS to application or have unspecified other impact. These functions failed to check for an out-of-range palette when reading or writing PNG files with a bitdepth less than 8. Some applications might read the bit depth from the IHDR chunk and allocate memory for a 2^N entry palette, while libpng can return a palette with up to 256 entries even when the bit depth is less than 8.

Affected versions of libpng are before 1.0.64, 1.1.x and 1.2.x before 1.2.54, 1.3.x and 1.4.x before 1.4.17, 1.5.x before 1.5.24, and 1.6.x before 1.6.19.

Upstream patches:

https://github.com/glennrp/libpng/commit/81f44665cce4cb1373f049a76f3904e981b7a766 https://github.com/glennrp/libpng/commit/a901eb3ce6087e0afeef988247f1a1aa208cb54d https://github.com/glennrp/libpng/commit/1bef8e97995c33123665582e57d3ed40b57d5978 https://github.com/glennrp/libpng/commit/83f4c735c88e7f451541c1528d8043c31ba3b466 https://github.com/glennrp/libpng/commit/9f2ad4928e47036cf1ac9b8fe45a491f15be2324

CVE assignment:

http://seclists.org/oss-sec/2015/q4/264

An Out-Of-Bounds Read vulnerability in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This flaw could allow a local attacker to crash the system or leak internal kernel information.

Refer; https://bugzilla.kernel.org/showbug.cgi?id=218218

[1] Retrieve WordCount and add offset2 to the data part of smb [2] Retrieve a 16-byte value from the calculated pointer

c unsigned int smbCalcSize(void buf) { struct smbhdr ptr = buf; return (sizeof(struct smbhdr) + (2 ptr->WordCount) + 2 / size of the bcc field / + getbcc(ptr)); } ... static inline u16 getbcc(struct smbhdr hdr) { le16 bcptr = (le16 )BCC(hdr);

return getunalignedle16(bcptr);//[2] } ... static inline void BCC(struct smbhdr smb) { return (void )smb + sizeof(smb) + 2 smb->WordCount; //[1] }

[2] cifsdemultiplexthread → standardreceive3 → cifshandlestandard → checkSMB → smbCalcSize

c int checkSMB(char buf, unsigned int totalread, struct TCPServerInfo server) { struct smbhdr smb = (struct smbhdr )buf; u32 rfclen = be32tocpu(smb->smbbuflength); u32 clclen; / calculated length / cifsdbg(FYI, "checkSMB Length: 0x%x, smbbuflength: 0x%x\n", totalread, rfclen);

/ is this frame too small to even get to a BCC? / if (totalread < 2 + sizeof(struct smbhdr)) { ... }

/ otherwise, there is enough to get to the BCC / if (checksmbhdr(smb)) return -EIO; clclen = smbCalcSize(smb);

A flaw has been identified in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the nssgethostbyname2r and nssgetcanonnamer hooks without implementing the nssgethostbyname3r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AFINET6 address family with AICANONNAME, AIALL and AIV4MAPPED as flags.

A flaw was found in glibc. When the getaddrinfo function is called with the AFUNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash.

A flaw in the Linux Kernel found in the GFS2 file system. On corrupted gfs2 file systems the evict code can try to reference the journal descriptor structure, jdesc, after it has been freed and set to NULL. It can lead to null pointer dereference when gfs2transbegin being called and then fail ingfs2evictinode().

Reference: https://listman.redhat.com/archives/cluster-devel/2023-April/023914.html

A vulnerability was found in openldap that can cause a null pointer dereference in the bermemallocx() function.

A use-after-free flaw was found in nfsd4sscsetupdul in fs/nfsd/nfs4proc.c in the NFS filesystem in the Linux Kernel. This issue could allow a local attacker to crash the system or it may lead to a kernel information leak problem.

In nftablesupdtable, if nftablestableenable returns an error, nfttransdestroy is called to free the transaction object. nfttransdestroy() calls listdel(), but the transaction was never placed on a list -- the list head is all zeroes, this results in a NULL pointer dereference.

A flaw in the Linux Kernel found in the Linux kernel’s networking stack which permits attackers to force hash collisions in the IPv6 connection lookup table. This results in a significant increase in the cost of lookups, causing increased CPU utilization. This significant CPU usage increase in the Linux kernel subjected to a modified form of the classic IPv6 SYN-Flood. The actual impact of this issue may be a denial of service (due to heightened CPU usage) to hosts which can receive malicious IPv6 traffic.

A buffer-underflow vulnerability exists in GLib’s GVariant parser, specifically within bytestringparse() and stringparse(). The parser uses signed 32-bit integers (gint) as loop indices (i and j). When extremely large strings are parsed, these counters overflow into negative values, causing the parser to write to memory before the start of the allocated buffer (str[j++]). This results in a classic out-of-bounds write condition. Because GVariant parsing is often performed on attacker-influenced data, a remote attacker can trigger heap corruption, causing a crash or potentially achieving code execution. This flaw has been confirmed by maintainers and patched upstream.

A flaw was found in libarchive. On 32-bit systems, an integer overflow vulnerability exists in the zisofs block pointer allocation logic. A remote attacker can exploit this by providing a specially crafted ISO9660 image, which can lead to a heap buffer overflow. This could potentially allow for arbitrary code execution on the affected system.