Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: cmis: require exact CDB reply length<br /> <br /> Malicious SFP module could respond with rpl_len longer than<br /> what cmis_cdb_process_reply() expected, leading to OOB writes.<br /> Malicious HW is a bit theoretical but some modules may just<br /> be buggy and/or the reads may occasionally get corrupted,<br /> so let&amp;#39;s protect the kernel.<br /> <br /> The existing check protects from short replies. We need to<br /> protect from long ones, too. All callers that pass a non-zero<br /> rpl_exp_len cast the reply payload to a fixed-layout struct<br /> and read fields at fixed offsets, with no version negotiation<br /> or short-reply handling:<br /> <br /> - cmis_cdb_validate_password()<br /> - cmis_cdb_module_features_get()<br /> - cmis_fw_update_fw_mng_features_get()<br /> <br /> so let&amp;#39;s assume that responses longer than expected do not<br /> have to be handled gracefully here. Add a warning message<br /> to make the debug easier in case my understanding is wrong...<br /> <br /> Note that page_data-&gt;length (argument of kmalloc) comes from<br /> last arg to ethtool_cmis_page_init() which is rpl_exp_len.<br /> <br /> Note2 that AIs also like to point out overflows in args-&gt;req.payload<br /> itself (which is a fixed-size 120 B buffer, on the stack),<br /> but callers should be reading structs defined by the standard,<br /> so protecting from requests for more data than max seem like<br /> defensive programming.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ethtool: module: avoid leaking a netdev ref on module flash errors<br /> <br /> module_flash_fw_schedule() is missing undo for setting<br /> the "in_progress" flag and taking the netdev reference.<br /> Delay taking these, the device can&amp;#39;t disappear while<br /> we are holding rtnl_lock.