From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 73C47C6FA82 for ; Mon, 26 Sep 2022 02:39:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232860AbiIZCje (ORCPT ); Sun, 25 Sep 2022 22:39:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232575AbiIZCj1 (ORCPT ); Sun, 25 Sep 2022 22:39:27 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B151638A6 for ; Sun, 25 Sep 2022 19:39:25 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id p14so2392138pjd.3 for ; Sun, 25 Sep 2022 19:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=rNfKV091B020Efc+YRWSdOa5mhQUV0Kl4OyiKcHkZ9Q=; b=kh1BUFDjkrLOhsENJ07K39+e7g1gEH4tc3sMPWx+sF3myjmnrJjs/Tx3sY8M4PaCUo oIJmzH7gjKTkasxkN/feO5ML/XlyTNFcju7NaZmfuNzK0D6eW02grt1GrxXFVe5OEnGE mm0bEdnQTbysRH54a1XnMMvqrTSmMCwvKJuao= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=rNfKV091B020Efc+YRWSdOa5mhQUV0Kl4OyiKcHkZ9Q=; b=b24BxgUUxO5TepXXEdYFDqRTRuAwhV7PzL0OC1H1zXuoprl1eCZ0+LpXzG44FVQnry si/BI7/NoW4ntOMkO7BCM2jgA0xyEt5jnxsmfHqpvF9ehzwheapLn/v/EIIB8MwwdyeI JYVEhbK62mvVR82z2xZaUZNepiYhvAGq5E12n6qrnmwb8Q3Kn8BDuZnx/78d72P+O36y XWITQ4SQnwFe5HJgMve+c9hDvGJSCL3e/I8Na9GqDGxi2HymISQrBxw9O4VGFkDEQ1ur chGg1z4i6OYP+vanAekq7fqS/uva3nhuRSfSyBqJZDgYz/xekvGjNdO+7drrKN2DhN4y ShNQ== X-Gm-Message-State: ACrzQf1XcvU42ibu8r05jFTR4fhJfLdTUMaWJwDExVbIG+j63X7+eAii tw+CfBZojliCxbYVcBNPzXox3w== X-Google-Smtp-Source: AMsMyM6BbKHm0noocBjB++zZR9GVYSdMb3IIGaKOhSxMq5KaQdZv9li5+4eICtAO3wxttWksScUPuw== X-Received: by 2002:a17:902:f389:b0:178:9bd4:b72e with SMTP id f9-20020a170902f38900b001789bd4b72emr19464384ple.140.1664159965206; Sun, 25 Sep 2022 19:39:25 -0700 (PDT) Received: from www.outflux.net (smtp.outflux.net. [198.145.64.163]) by smtp.gmail.com with ESMTPSA id p4-20020a622904000000b0054d1a2ee8cfsm10666756pfp.103.2022.09.25.19.39.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Sep 2022 19:39:24 -0700 (PDT) Date: Sun, 25 Sep 2022 19:39:23 -0700 From: Kees Cook To: Eric Dumazet Cc: Jamal Hadi Salim , syzbot , David Miller , Jiri Pirko , Jakub Kicinski , LKML , netdev , Paolo Abeni , syzkaller-bugs , Cong Wang Subject: Re: [syzbot] WARNING in u32_change Message-ID: <202209251935.0469930C@keescook> References: <000000000000a96c0b05e97f0444@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 25, 2022 at 10:34:37AM -0700, Eric Dumazet wrote: > Sure, please look at: > > commit 54d9469bc515dc5fcbc20eecbe19cea868b70d68 > Author: Kees Cook > Date: Thu Jun 24 15:39:26 2021 -0700 > > fortify: Add run-time WARN for cross-field memcpy() > [...] > Here, we might switch to unsafe_memcpy() instead of memcpy() I would tend to agree. Something like: diff --git a/net/sched/cls_u32.c b/net/sched/cls_u32.c index 4d27300c287c..21e0e6206ecc 100644 --- a/net/sched/cls_u32.c +++ b/net/sched/cls_u32.c @@ -1040,7 +1040,9 @@ static int u32_change(struct net *net, struct sk_buff *in_skb, } #endif - memcpy(&n->sel, s, sel_size); + unsafe_memcpy(&n->sel, s, sel_size, + /* A composite flex-array structure destination, + * which was correctly sized and allocated above. */); RCU_INIT_POINTER(n->ht_up, ht); n->handle = handle; n->fshift = s->hmask ? ffs(ntohl(s->hmask)) - 1 : 0; This alloc/partial-copy pattern is relatively common in the kernel, so I've been considering adding a helper for it. It'd be like kmemdup(), but more like kmemdup_offset(), which only the object from a certainly point is copied. -- Kees Cook