From patchwork Tue Feb 25 14:40:03 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jiayuan Chen X-Patchwork-Id: 13990094 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) (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 6C60521ABC4 for ; Tue, 25 Feb 2025 14:40:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.181 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740494430; cv=none; b=nk23T6FcDpwoBrJ55E4sYEKIYZb+KGM5LCup4ER9AFxQ9dQ2cys1VFRkeDu49pryT47YOWgPmpA6zg7GbOyWhgKp+d8PU6zafcUG+kiYo+9IualGP1TEtAtjHT7jGy1X1GkG36quxHAa2E5vbuqNORvE3KerVz2r/DLil47hHqk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740494430; c=relaxed/simple; bh=Gcu0/y2YMP2LlNhJAtEESlhx/D3SReNbDRxbsrVxZnM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=uJsrOFvDRSWUn0tzbh3nnrPExa9bSPLRhwdCytsFSDqKNz5AjSYSxf9J/Fsz9T1G+YnhL57gQNWP/jXfVTY3iTBh+Qw7AYz3ctiMCT3QTDJ6qYAp9kM4NOxHC1a+bJYGJ9//Vkdj8usDDKrERT73u7abqP/pkBeqVwOh3QvO0R4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=O/xgNeZU; arc=none smtp.client-ip=95.215.58.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="O/xgNeZU" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740494415; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=RLRUQ6K3ZxrvBuZuKZAonhzQHThtxFHbpTnpSZBjIXA=; b=O/xgNeZU7zk6zS7kTLRt0naInEXik3C/Jeirb8KGy2+4zmAONIGQJAXkW1OLlKpAGI9LVJ /HBQmNyVhxSpxfKe3kk0YTr/L7SvFijVqO2uGQ29nrDGKr6ebZmLFylSpVoIkay66mSfA9 1o4QNWsBxZ2ieE1FJYnin6QLGnP6eUs= From: Jiayuan Chen To: horms@kernel.org, kuba@kernel.org Cc: bpf@vger.kernel.org, netdev@vger.kernel.org, andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, ricardo@marliere.net, viro@zeniv.linux.org.uk, dmantipov@yandex.ru, aleksander.lobakin@intel.com, linux-ppp@vger.kernel.org, linux-kernel@vger.kernel.org, mrpre@163.com, Jiayuan Chen , Paul Mackerras Subject: [PATCH net-next 0/1] ppp: Fix KMSAN uninit-value warning with bpf Date: Tue, 25 Feb 2025 22:40:03 +0800 Message-ID: <20250225144004.277169-1-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Migadu-Flow: FLOW_OUT X-Patchwork-Delegate: kuba@kernel.org Syzbot caught an "KMSAN: uninit-value" warning [1], which is caused by the ppp driver not initializing a 2-byte header when using socket filters. Here's a detailed explanation: The following code can generate a PPP filter BPF program: ''' struct bpf_program fp; pcap_t *handle; handle = pcap_open_dead(DLT_PPP_PPPD, 65535); pcap_compile(handle, &fp, "ip and outbound", 0, 0); bpf_dump(&fp, 1); ''' Its output is: ''' (000) ldh [2] (001) jeq #0x21 jt 2 jf 5 (002) ldb [0] (003) jeq #0x1 jt 4 jf 5 (004) ret #65535 (005) ret #0 ''' wen can find similar code at the following link: https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680 The maintainer of this code repository is also the original maintainer of the ppp driver. 3. Current problem The problem is that the skb->data generated by ppp_write() starts from the 'Protocol' field. But the BPF program skips 2 bytes of data and then reads the 'Protocol' field to determine if it's an IP packet just like the comment in 'drivers/net/ppp/ppp_generic.c': /* the filter instructions are constructed assuming a four-byte PPP header on each packet */ In the current PPP driver implementation, to correctly use the BPF filter program, a 2-byte header is added, after running the socket filter, it's restored: ''' 1768 *(u8 *)skb_push(skb, 2) = 1; 1770 bpf_prog_run() 1782 skb_pull(skb, 2); ''' The issue is that only the first byte indicating direction is initialized, while the second byte is not initialized. For normal BPF programs generated by libpcap, uninitialized data won't be used, so it's not a problem. However, for carefully crafted BPF programs, such as those generated by syzkaller [2], which start reading from offset 0, the uninitialized data will be used and caught by KMSAN. 4. Fix The fix is simple: initialize the entire 2-byte header. Cc: Paul Mackerras [1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791 [2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000 --- v3 -> v4: Use macro instead. Jiayuan Chen (1): ppp: Fix KMSAN warning by initializing 2-byte header drivers/net/ppp/ppp_generic.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)