From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 313D96BFD2 for ; Thu, 4 Apr 2024 08:24:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712219058; cv=none; b=VtSKsoCJ5D8ogj+1eMlAZrIfCBM1S+z6hM/CYTlr3dirSvEkmBy6c3l+BolukZjDOboYbGVRraJyD+WoAgdPIk2cheAFGlJL8CUkONYOpWRjBH+vXxAkngwf9iDL32DUr6IjSt1fGsSRVFNpsAFDUkTCtr76p8cI8XaqFc5TZ2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712219058; c=relaxed/simple; bh=jYEJeL13Osg+Lg6nOaBIrk0GRvFHtl+sxbdjSwOvdwM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=dKVZ94aywEmC5YObbIZrQiwZjE3Ll1+XVVaqUyhFbwt9sEcYJ4x5FCpNzNm5hWbFoj0ITpqJbNNR0j6lb5+sjuRg1/qp9eEQKy35ALPItgsSQUTwJ/dHVE405XHCBI3esZoTuw4k0Thx5ckIUG9Syzbtmx1Aygg9MsNUM+WOdIw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=cmjNFn+D; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="cmjNFn+D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F0D8C433C7; Thu, 4 Apr 2024 08:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1712219057; bh=jYEJeL13Osg+Lg6nOaBIrk0GRvFHtl+sxbdjSwOvdwM=; h=From:To:Cc:Subject:Date:Reply-to:From; b=cmjNFn+DLLYqVwHb+Df4ssXj3R24hE+IHiRzV6U4dcwzRHRQf2GpKO2xJWAvYh2/q 47+MESEPlKe15ycAOLPyJgi9NdB6+RW/V2hlNxMkSSCWysPGW4XEhsfIVvdTal9R+z HtGOHHiSdr2hqukqP74dNol3ZgB3w0obw4JKYwDc= From: Greg Kroah-Hartman To: linux-cve-announce@vger.kernel.org Cc: Greg Kroah-Hartman Subject: CVE-2024-26804: net: ip_tunnel: prevent perpetual headroom growth Date: Thu, 4 Apr 2024 10:23:21 +0200 Message-ID: <2024040404-CVE-2024-26804-a6ff@gregkh> X-Mailer: git-send-email 2.44.0 Precedence: bulk X-Mailing-List: linux-cve-announce@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Reply-to: , X-Developer-Signature: v=1; a=openpgp-sha256; l=6434; i=gregkh@linuxfoundation.org; h=from:subject:message-id; bh=jYEJeL13Osg+Lg6nOaBIrk0GRvFHtl+sxbdjSwOvdwM=; b=owGbwMvMwCRo6H6F97bub03G02pJDGl8yRlcF+2urO/Mfakz+3dF9WE+G5+i8oerpzEv2yJZL Cm2++u0jlgWBkEmBlkxRZYv23iO7q84pOhlaHsaZg4rE8gQBi5OAZgIUP08uxPblfnesWwVCtTI mzTNdFF349ZnDPOzDNcZHKuZ0zohiUPx7HPFXUnym0oA X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit Description =========== In the Linux kernel, the following vulnerability has been resolved: net: ip_tunnel: prevent perpetual headroom growth syzkaller triggered following kasan splat: BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191 [..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ... The splat occurs because skb->data points past skb->head allocated area. This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb)); ... but skb_network_offset() returns a negative offset and __skb_pull() arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value. The negative value is returned because skb->head and skb->data distance is more than 64k and skb->network_header (u16) has wrapped around. The bug is in the ip_tunnel infrastructure, which can cause dev->needed_headroom to increment ad infinitum. The syzkaller reproducer consists of packets getting routed via a gre tunnel, and route of gre encapsulated packets pointing at another (ipip) tunnel. The ipip encapsulation finds gre0 as next output device. This results in the following pattern: 1). First packet is to be sent out via gre0. Route lookup found an output device, ipip0. 2). ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the future output device, rt.dev->needed_headroom (ipip0). 3). ip output / start_xmit moves skb on to ipip0. which runs the same code path again (xmit recursion). 4). Routing step for the post-gre0-encap packet finds gre0 as output device to use for ipip0 encapsulated packet. tunl0->needed_headroom is then incremented based on the (already bumped) gre0 device headroom. This repeats for every future packet: gre0->needed_headroom gets inflated because previous packets' ipip0 step incremented rt->dev (gre0) headroom, and ipip0 incremented because gre0 needed_headroom was increased. For each subsequent packet, gre/ipip0->needed_headroom grows until post-expand-head reallocations result in a skb->head/data distance of more than 64k. Once that happens, skb->network_header (u16) wraps around when pskb_expand_head tries to make sure that skb_network_offset() is unchanged after the headroom expansion/reallocation. After this skb_network_offset(skb) returns a different (and negative) result post headroom expansion. The next trip to neigh layer (or anything else that would __skb_pull the network header) makes skb->data point to a memory location outside skb->head area. v2: Cap the needed_headroom update to an arbitarily chosen upperlimit to prevent perpetual increase instead of dropping the headroom increment completely. The Linux kernel CVE team has assigned CVE-2024-26804 to this issue. Affected and fixed versions =========================== Issue introduced in 2.6.34 with commit 243aad830e8a and fixed in 5.4.271 with commit f81e94d2dcd2 Issue introduced in 2.6.34 with commit 243aad830e8a and fixed in 5.10.212 with commit 2e95350fe9db Issue introduced in 2.6.34 with commit 243aad830e8a and fixed in 5.15.151 with commit afec0c5cd2ed Issue introduced in 2.6.34 with commit 243aad830e8a and fixed in 6.1.81 with commit ab63de24ebea Issue introduced in 2.6.34 with commit 243aad830e8a and fixed in 6.6.21 with commit a0a1db40b23e Issue introduced in 2.6.34 with commit 243aad830e8a and fixed in 6.7.9 with commit 049d7989c67e Issue introduced in 2.6.34 with commit 243aad830e8a and fixed in 6.8 with commit 5ae1e9922bbd Please see https://www.kernel.org for a full list of currently supported kernel versions by the kernel community. Unaffected versions might change over time as fixes are backported to older supported kernel versions. The official CVE entry at https://cve.org/CVERecord/?id=CVE-2024-26804 will be updated if fixes are backported, please check that for the most up to date information about this issue. Affected files ============== The file(s) affected by this issue are: net/ipv4/ip_tunnel.c Mitigation ========== The Linux kernel CVE team recommends that you update to the latest stable kernel version for this, and many other bugfixes. Individual changes are never tested alone, but rather are part of a larger kernel release. Cherry-picking individual commits is not recommended or supported by the Linux kernel community at all. If however, updating to the latest release is impossible, the individual changes to resolve this issue can be found at these commits: https://git.kernel.org/stable/c/f81e94d2dcd2397137edcb8b85f4c5bed5d22383 https://git.kernel.org/stable/c/2e95350fe9db9d53c701075060ac8ac883b68aee https://git.kernel.org/stable/c/afec0c5cd2ed71ca95a8b36a5e6d03333bf34282 https://git.kernel.org/stable/c/ab63de24ebea36fe73ac7121738595d704b66d96 https://git.kernel.org/stable/c/a0a1db40b23e8ff86dea2786c5ea1470bb23ecb9 https://git.kernel.org/stable/c/049d7989c67e8dd50f07a2096dbafdb41331fb9b https://git.kernel.org/stable/c/5ae1e9922bbdbaeb9cfbe91085ab75927488ac0f