Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: button: Fix ACPI GPE handler leak during removal<br /> <br /> Commit a7e23ec17fee ("ACPI: button: Install notifier for system events<br /> as well") changed the ACPI notify handler type for ACPI buttons to<br /> ACPI_ALL_NOTIFY, but it forgot to update acpi_button_remove() to reflect<br /> that change. This leads to leaking the notify handler past driver<br /> removal, which may cause a kernel crash to occur if ACPI notify on<br /> the given device is triggered after removing the driver, and causes a<br /> subsequent probe of the given device with the same driver to fail.<br /> <br /> Address this by updating the acpi_remove_notify_handler() call in<br /> acpi_button_remove() as appropriate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: usbtouchscreen - clamp NEXIO data_len/x_len to URB buffer size<br /> <br /> nexio_read_data() pulls data_len and x_len from a packed __be16 header<br /> in the device&amp;#39;s interrupt packet and then walks packet-&gt;data[0..x_len)<br /> and packet-&gt;data[x_len..data_len) comparing each byte against a<br /> threshold.<br /> <br /> Both fields are 16-bit on the wire (max 65535). The existing<br /> adjustments shave at most 0x100 / 0x80 off, so the loop bound can still<br /> reach roughly 0xfeff. The URB transfer buffer for NEXIO is rept_size<br /> (1024) bytes from usb_alloc_coherent(), with the first 7 occupied by the<br /> packed header — so packet-&gt;data[] has 1017 valid bytes. read_data()<br /> callbacks are not given urb-&gt;actual_length, and nothing else bounds the<br /> walk.<br /> <br /> A device that lies about its length can get a ~64 KiB out-of-bounds read<br /> past the coherent DMA allocation. The first index whose byte exceeds<br /> NEXIO_THRESHOLD lands in begin_x / begin_y and from there into the<br /> reported touch coordinates, so adjacent kernel memory contents leak to<br /> userspace as ABS_X / ABS_Y events. Far enough out, the read can also<br /> hit an unmapped page and fault.<br /> <br /> Fix this all by clamping data_len to the buffer&amp;#39;s data[] capacity and<br /> x_len to data_len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix dma mapping leak on data setup error<br /> <br /> We&amp;#39;re leaking the initial DMA mapping during iteration if we fail to<br /> allocate the tracking descriptor for both PRP and SGL. Unmap the<br /> iterator directly; we can&amp;#39;t use the existing unmap helper because it<br /> depends on the tracking descriptor being successfully allocated, so a<br /> new one for an in-use iterator is provided.<br /> <br /> The mappings were also leaking when the driver detects an invalid<br /> bio_vec when mapping PRPs, so fix that too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/iucv: fix locking in .getsockopt<br /> <br /> Mirror iucv_sock_setsockopt() and wrap the whole switch in<br /> lock_sock()/release_sock(). The pre-existing SO_MSGLIMIT-only lock<br /> becomes redundant and is removed.<br /> <br /> Any AF_IUCV HIPER user can potentially crash the kernel by racing<br /> recvmsg() with getsockopt(SO_MSGSIZE): the SO_MSGSIZE arm dereferences<br /> iucv-&gt;hs_dev-&gt;mtu after iucv_sock_close() (called from the racing<br /> recvmsg()) has set hs_dev to NULL, producing a NULL pointer dereference<br /> oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Do not re-initialize smc hashtables<br /> <br /> INIT_HLIST_HEAD(&amp;smc_v*_hashinfo.ht) are called after smc_nl_init(),<br /> proto_register() and sock_register(). This can lead to smc_v*_hashinfo.ht<br /> being reset even though hash entries already exist and are being used,<br /> possibly resulting in a corrupted list.<br /> <br /> Remove unnecessary and dangerous re-initialisation of smc_v*_hashinfo.ht in<br /> smc_init(); it is implicitly initialised to zero anyhow. Add<br /> HLIST_HEAD_INIT to the definitions for clarity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: synproxy: refresh tcphdr after skb_ensure_writable<br /> <br /> synproxy_tstamp_adjust() rewrites the TCP timestamp option in place<br /> and then patches the TCP checksum via inet_proto_csum_replace4() on<br /> the caller-supplied tcphdr pointer. Both ipv4_synproxy_hook() and<br /> ipv6_synproxy_hook() obtain that pointer with skb_header_pointer()<br /> before calling in, so it may either alias skb-&gt;head directly or<br /> point at the caller&amp;#39;s on-stack _tcph buffer.<br /> <br /> Between obtaining the pointer and using it, the function calls<br /> skb_ensure_writable(skb, optend), which on a cloned or non-linear<br /> skb invokes pskb_expand_head() and frees the old skb-&gt;head. After<br /> that point the cached th is stale:<br /> <br /> caller (ipv[46]_synproxy_hook)<br /> th = skb_header_pointer(skb, ..., &amp;_tcph)<br /> synproxy_tstamp_adjust(skb, protoff, th, ...)<br /> skb_ensure_writable(skb, optend)<br /> pskb_expand_head() /* kfree(old skb-&gt;head) */<br /> ...<br /> inet_proto_csum_replace4(&amp;th-&gt;check, ...)<br /> /* writes into freed head, or<br /> into the caller&amp;#39;s stack copy<br /> leaving the on-wire checksum<br /> stale */<br /> <br /> The option bytes are written through skb-&gt;data and are fine; only<br /> the checksum update goes through th and so lands in the wrong<br /> place. The result is either a write into freed slab memory or a<br /> packet leaving with a checksum that does not match its payload.<br /> <br /> Fix by re-deriving th from skb-&gt;data + protoff immediately after<br /> skb_ensure_writable() succeeds, so the subsequent checksum update<br /> targets the linear, writable header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/rocket: fix UAF via dangling GEM handle in create_bo<br /> <br /> rocket_ioctl_create_bo() inserts a GEM handle into the file&amp;#39;s IDR via<br /> drm_gem_handle_create() early on, then performs several operations that<br /> can fail (sgt allocation, drm_mm insert, iommu_map). If any fail after<br /> the handle is live, the error path calls drm_gem_shmem_object_free()<br /> which kfree&amp;#39;s the object without removing the handle from the IDR.<br /> <br /> This leaves a dangling handle pointing to freed slab memory. Any<br /> subsequent ioctl using that handle (PREP_BO, FINI_BO, SUBMIT) calls<br /> drm_gem_object_lookup() and dereferences freed memory (UAF).<br /> <br /> Fix by moving drm_gem_handle_create() to after all fallible operations<br /> succeed, matching the pattern used by panfrost, lima, and etnaviv.<br /> <br /> Also fix drm_mm_insert_node_generic() whose return value was silently<br /> overwritten by iommu_map_sgtable() on the next line. Add the missing<br /> error check.<br /> <br /> [tomeu: Move handle creation to the very end]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm: Check for underflow in xfrm_state_mtu<br /> <br /> Leo Lin reported OOB write issue in esp component:<br /> <br /> xfrm_state_mtu() returns u32 but performs its arithmetic in unsigned<br /> modulo-2^32 space using an attacker-influenced "header_len + authsize +<br /> net_adj" subtracted from a small "mtu" argument. A nobody user can<br /> install an IPv4 ESP tunnel SA with a large authentication key<br /> (XFRMA_ALG_AUTH_TRUNC, e.g. hmac(sha512), 64-byte key, 64-byte trunc),<br /> configure a small interface MTU (68 bytes), and set XFRMA_TFCPAD to a<br /> large value. When a single UDP datagram is then sent through the<br /> tunnel, xfrm_state_mtu() underflows to a near-2^32 value, and<br /> esp_output() consumes it as a signed int via:<br /> <br /> padto = min(x-&gt;tfcpad, xfrm_state_mtu(x, mtu_cached))<br /> esp.tfclen = padto - skb-&gt;len (assigned to int)<br /> <br /> esp.tfclen ends up negative (e.g. -207). It is sign-extended to size_t<br /> when passed to memset() inside esp_output_fill_trailer(), producing a<br /> ~16 EB write of zeroes at skb_tail_pointer(skb). KASAN logs it as<br /> "Write of size 18446744073709551537 at addr ffff888...".<br /> <br /> Check for underflow and return 1. This causes the sendmsg attempt to<br /> fail with ENETUNREACH.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: Fix use-after-free race in nfc_llcp_recv_cc()<br /> <br /> A race condition exists in the NFC LLCP connection state machine where<br /> the connection acceptance packet (CC) can be processed concurrently with<br /> socket release. This can lead to a use-after-free of the socket object.<br /> <br /> When nfc_llcp_recv_cc() moves the socket from the connecting_sockets<br /> list to the sockets list, it does so without holding the socket lock.<br /> If llcp_sock_release() is executing concurrently, it might have already<br /> unlinked the socket and dropped its references, which can result in<br /> nfc_llcp_recv_cc() linking a freed socket into the live list.<br /> <br /> Fix this by holding lock_sock() during the state transition and list<br /> movement in nfc_llcp_recv_cc(). After acquiring the lock, check if<br /> the socket is still hashed to ensure it hasn&amp;#39;t already been unlinked<br /> and marked for destruction by the release path. This aligns the locking<br /> pattern with recv_hdlc() and recv_disc().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: llcp: Fix use-after-free in llcp_sock_release()<br /> <br /> llcp_sock_release() unconditionally unlinks the socket from the local<br /> sockets list. However, if the socket is still in connecting state, it<br /> is on the connecting list.<br /> <br /> Fix this by checking the socket state and unlinking from the correct list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: fix dst corruption in same register operation<br /> <br /> For lshift and rshift, the shift operations are performed in a loop over<br /> 32-bit words. The loop calculates the shifted value and write it to dst,<br /> and then immediately reads from src to calculate the carry for the next<br /> iteration. Because src and dst could point to the same memory location,<br /> the carry is incorrectly calculated using the newly modified dst value<br /> instead of the original src value.<br /> <br /> Adding a temporary local variable to cache the original value before<br /> writing to dst and using it for the carry calculation solves the<br /> problem. In addition, partial overlap is rejected from control plane for<br /> all kind of operations including byteorder. This was tested with the<br /> following bytecode:<br /> <br /> table test_table ip flags 0 use 1 handle 1<br /> ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1<br /> ip test_table test_chain 2<br /> [ immediate reg 1 0x44332211 0x88776655 ]<br /> [ bitwise reg 1 = ( reg 1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: cmis: validate start_cmd_payload_size from module<br /> <br /> The CMIS firmware update code reads start_cmd_payload_size from<br /> the module&amp;#39;s FW Management Features CDB reply and uses it directly<br /> as the byte count for memcpy. The destination buffer is 112 bytes<br /> (ETHTOOL_CMIS_CDB_LPL_MAX_PL_LENGTH - 8). So a malicious<br /> module (or corrupted response) can cause a OOB write later on in<br /> cmis_fw_update_start_download().<br /> <br /> Let&amp;#39;s error out. If modules that expect longer LPL writes actually<br /> exist we should revisit.<br /> <br /> struct cmis_cdb_start_fw_download_pl&amp;#39;s definition has to move,<br /> no change there.