undici WebSocket client vulnerable to Denial of Service via failed HTTP/2 handshake

undici is an HTTP client library for Node.js. In versions 8.11.0 and 8.11.1, its experimental WebSocket client, which is enabled by default when HTTP/2 is allowed, mishandles a failed WebSocket handshake over HTTP/2: the request is already marked completed, so the abort becomes a no-op and the underlying HTTP/2 stream is left open with no error listener. When a malicious server then destroys the connection, the orphaned stream emits an unhandled error and the Node.js process exits. A remote, unauthenticated server can therefore crash any client that opens a WebSocket to it over HTTP/2, resulting in a denial of service. The issue is fixed in undici 8.11.2, and users should upgrade to 8.11.2 or later. As a workaround, set allowH2 to false to disable HTTP/2 for WebSocket connections, or avoid opening WebSocket connections to untrusted servers.

net: consume xmit errors of GSO frames

In the Linux kernel, the following vulnerability has been resolved: net: consume xmit errors of GSO frames udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min. These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on. Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]). In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4*MSS:N-3*MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck. The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this: ------------------------------------------------- | GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ------------------------------------------------- x ok ok <ok>| ok ok ok <x> \\ snd_nxt "x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent. So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above). Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely. We have multiple ways to fix this. 1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great. 2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer. 3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss? 4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix? Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).

KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation

In the Linux kernel, the following vulnerability has been resolved: KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload of guest state") made KVM always use vmcb01 for the fields controlled by VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code to always use vmcb01. As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01 instead of the current VMCB.

btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref()

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix incorrect return value after changing leaf in lookup_extent_data_ref() After commit 1618aa3c2e01 ("btrfs: simplify return variables in lookup_extent_data_ref()"), the err and ret variables were merged into a single ret variable. However, when btrfs_next_leaf() returns 0 (success), ret is overwritten from -ENOENT to 0. If the first key in the next leaf does not match (different objectid or type), the function returns 0 instead of -ENOENT, making the caller believe the lookup succeeded when it did not. This can lead to operations on the wrong extent tree item, potentially causing extent tree corruption. Fix this by returning -ENOENT directly when the key does not match, instead of relying on the ret variable.

rxrpc: reject undecryptable rxkad response tickets

In the Linux kernel, the following vulnerability has been resolved: rxrpc: reject undecryptable rxkad response tickets rxkad_decrypt_ticket() decrypts the RXKAD response ticket and then parses the buffer as plaintext without checking whether crypto_skcipher_decrypt() succeeded. A malformed RESPONSE can therefore use a non-block-aligned ticket length, make the decrypt operation fail, and still drive the ticket parser with attacker-controlled bytes. Check the decrypt result and abort the connection with RXKADBADTICKET when ticket decryption fails.

dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()

In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc() At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop.

netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels

In the Linux kernel, the following vulnerability has been resolved: netfilter: xt_IDLETIMER: reject rev0 reuse of ALARM timer labels IDLETIMER revision 0 rules reuse existing timers by label and always call mod_timer() on timer->timer. If the label was created first by revision 1 with XT_IDLETIMER_ALARM, the object uses alarm timer semantics and timer->timer is never initialized. Reusing that object from revision 0 causes mod_timer() on an uninitialized timer_list, triggering debugobjects warnings and possible panic when panic_on_warn=1. Fix this by rejecting revision 0 rule insertion when an existing timer with the same label is of ALARM type.

libceph: return the handler error from mon_handle_auth_done()

In the Linux kernel, the following vulnerability has been resolved: libceph: return the handler error from mon_handle_auth_done() Currently any error from ceph_auth_handle_reply_done() is propagated via finish_auth() but isn't returned from mon_handle_auth_done(). This results in higher layers learning that (despite the monitor considering us to be successfully authenticated) something went wrong in the authentication phase and reacting accordingly, but msgr2 still trying to proceed with establishing the session in the background. In the case of secure mode this can trigger a WARN in setup_crypto() and later lead to a NULL pointer dereference inside of prepare_auth_signature().

RabbitMQ: AMQP 1.0 symbolic body descriptor prefix collisions bypass validation

RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.24, 4.1.15, 4.2.10, and 4.3.4, the optimized AMQP 1.0 server_mode parser in deps/amqp10_common/src/amqp10_binary_parser.erl matches the textual prefixes of symbolic data, sequence, and value body descriptors without verifying their encoded symbol lengths. An authenticated AMQP 1.0 publisher with write permission can submit a well-formed unknown descriptor that begins with a registered body descriptor, and RabbitMQ misclassifies and stores the bytes as a standard body section. Strict AMQP 1.0 consumers can terminate while decoding the stored entry. For bodies misclassified as data, AMQP 0-9-1 or other cross-protocol conversion performs full body decoding and can terminate the consumer protocol process, with acknowledgement-required delivery permitting repeated failures. Sequence and value classifications are normally transported as opaque encoded payloads on that conversion path. The broker remains alive, and the issue does not bypass routing or authorization. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4.

Junos OS: MX Series with SPC3: In a source NAT scenario malformed packets will lead to resource leaks and eventually traffic stops

An Improper Check for Unusual or Exceptional Conditions vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on MX Series with SPC3 allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS). On MX Series with SPC3 line-card and source NAT configuration, when a specific malformed IPv6 packet is received, it is not dropped but instead a session is created and NAT resources are allocated. Continued receipt of such packets will eventually lead to session or resource exhaustion, which will impact all traffic through the device. To recover the device needs to be rebooted. To monitor session usage, use the following: show services sessions summary To monitor source NAT resource usage, use the following:  show services nat pool This issue affects Junos OS on MX Series with SPC3: * All versions before 23.2R2-S4; * 23.4 versions before 23.4R2-S5; * 24.2 versions before 24.2R2.

FreeRDP 3.0.0 before 3.32.0 Security Protocol Downgrade via Negotiation Response

The FreeRDP client 3.0.0 before 3.32.0 does not check a server-selected PROTOCOL_RDSTLS or PROTOCOL_HYBRID_EX against its enabled protocol set in nego_process_negotiation_response(), allowing a security protocol downgrade. A malicious server or man-in-the-middle can select RDSTLS to override /sec:nla pinning, complete authentication with an all-zero cookie, and receive the user's cleartext password in the Client Info PDU.

net: fib_rules: Don't dump dying fib_rule in fib_rules_dump().

In the Linux kernel, the following vulnerability has been resolved: net: fib_rules: Don't dump dying fib_rule in fib_rules_dump(). rocker_router_fib_event() calls fib_rule_get() during RCU dump. If the fib_rule is dying, refcount_inc() will complain about it. Let's call refcount_inc_not_zero() in fib_rules_dump().

Backstage: Incorrect authorization in search engine permission filtering

Backstage is an open framework for building developer portals. Prior to 2.1.6 in @backstage/plugin-search-backend and 1.8.7 in @backstage/plugin-search-backend-module-elasticsearch, search engine permission filtering could return documents denied by policy. An authenticated Backstage user subject to a DENY policy for search document types could receive unauthorized results in deployments with permission.enabled set to true and an Elasticsearch or OpenSearch backend. This issue is fixed in @backstage/plugin-search-backend 2.1.6 and @backstage/plugin-search-backend-module-elasticsearch 1.8.7.

sunrpc: fix handling of server side tls alerts

In the Linux kernel, the following vulnerability has been resolved: sunrpc: fix handling of server side tls alerts Scott Mayhew discovered a security exploit in NFS over TLS in tls_alert_recv() due to its assumption it can read data from the msg iterator's kvec.. kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer. This patch proposes to rework how control messages are setup and used by sock_recvmsg(). If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tls_alert_recv.

scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()

In the Linux kernel, the following vulnerability has been resolved: scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port() The function core_scsi3_decode_spec_i_port(), in its error code path, unconditionally calls core_scsi3_lunacl_undepend_item() passing the dest_se_deve pointer, which may be NULL. This can lead to a NULL pointer dereference if dest_se_deve remains unset. SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg Unable to handle kernel paging request at virtual address dfff800000000012 Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod] Fix this by adding a NULL check before calling core_scsi3_lunacl_undepend_item()

virt: tdx-guest: Just leak decrypted memory on unrecoverable errors

In the Linux kernel, the following vulnerability has been resolved: virt: tdx-guest: Just leak decrypted memory on unrecoverable errors In CoCo VMs it is possible for the untrusted host to cause set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues. Leak the decrypted memory when set_memory_decrypted() fails, and don't need to print an error since set_memory_decrypted() will call WARN_ONCE().

tomcat: Security constrained bypass in error page mechanism

The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.

Nullsoft Scriptable Install System (NSIS) before 3.11 on Windows allows local users to escalate privileges to SYSTEM during an installation, because the temporary plugins directory is created under %WINDIR%\temp and unprivileged users can place a crafted executable file by winning a race condition. This occurs because EW_CREATEDIR does not always set the CreateRestrictedDirectory error flag.

PCI/IOV: Fix race between SR-IOV enable/disable and hotplug

In the Linux kernel, the following vulnerability has been resolved: PCI/IOV: Fix race between SR-IOV enable/disable and hotplug Commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV") tried to fix a race between the VF removal inside sriov_del_vfs() and concurrent hot unplug by taking the PCI rescan/remove lock in sriov_del_vfs(). Similarly the PCI rescan/remove lock was also taken in sriov_add_vfs() to protect addition of VFs. This approach however causes deadlock on trying to remove PFs with SR-IOV enabled because PFs disable SR-IOV during removal and this removal happens under the PCI rescan/remove lock. So the original fix had to be reverted. Instead of taking the PCI rescan/remove lock in sriov_add_vfs() and sriov_del_vfs(), fix the race that occurs with SR-IOV enable and disable vs hotplug higher up in the callchain by taking the lock in sriov_numvfs_store() before calling into the driver's sriov_configure() callback.

libexpat: expat: DoS via XML_ResumeParser

An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.