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 X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 141E2C433E0 for ; Mon, 3 Aug 2020 14:56:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E5F5C2076E for ; Mon, 3 Aug 2020 14:56:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727078AbgHCO4l (ORCPT ); Mon, 3 Aug 2020 10:56:41 -0400 Received: from www62.your-server.de ([213.133.104.62]:47790 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726773AbgHCO4l (ORCPT ); Mon, 3 Aug 2020 10:56:41 -0400 Received: from sslproxy05.your-server.de ([78.46.172.2]) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1k2btE-0001Go-5d; Mon, 03 Aug 2020 16:56:36 +0200 Received: from [178.196.57.75] (helo=pc-9.home) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2btD-0006D4-Us; Mon, 03 Aug 2020 16:56:35 +0200 Subject: Re: [PATCH net] net/bpfilter: initialize pos in __bpfilter_process_sockopt To: Alexei Starovoitov Cc: Christian Brauner , Christoph Hellwig , davem@davemloft.net, kuba@kernel.org, ast@kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Rodrigo Madera References: <20200730160900.187157-1-hch@lst.de> <20200730161303.erzgrhqsgc77d4ny@wittgenstein> <03954b8f-0db7-427b-cfd6-7146da9b5466@iogearbox.net> <20200801194846.dxmvg5fmg67nuhwy@ast-mbp.dhcp.thefacebook.com> From: Daniel Borkmann Message-ID: Date: Mon, 3 Aug 2020 16:56:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20200801194846.dxmvg5fmg67nuhwy@ast-mbp.dhcp.thefacebook.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.3/25892/Sun Aug 2 17:01:36 2020) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 8/1/20 9:48 PM, Alexei Starovoitov wrote: > On Fri, Jul 31, 2020 at 02:07:42AM +0200, Daniel Borkmann wrote: >> On 7/30/20 6:13 PM, Christian Brauner wrote: >>> On Thu, Jul 30, 2020 at 06:09:00PM +0200, Christoph Hellwig wrote: >>>> __bpfilter_process_sockopt never initialized the pos variable passed to >>>> the pipe write. This has been mostly harmless in the past as pipes >>>> ignore the offset, but the switch to kernel_write no verified the >>> >>> s/no/now/ >>> >>>> position, which can lead to a failure depending on the exact stack >>>> initialization patter. Initialize the variable to zero to make >>> >>> s/patter/pattern/ >>> >>>> rw_verify_area happy. >>>> >>>> Fixes: 6955a76fbcd5 ("bpfilter: switch to kernel_write") >>>> Reported-by: Christian Brauner >>>> Reported-by: Rodrigo Madera >>>> Signed-off-by: Christoph Hellwig >>>> Tested-by: Rodrigo Madera >>>> --- >>> >>> Thanks for tracking this down, Christoph! This fixes the logging issue >>> for me. >>> Tested-by: Christian Brauner >>> Reviewed-by: Christian Brauner >> >> Applied to bpf & fixed up the typos in the commit msg, thanks everyone! > > Daniel, > why is it necessary in bpf tree? > > I fixed it already in bpf-next in commit a4fa458950b4 ("bpfilter: Initialize pos variable") > two weeks ago... Several folks reported that with v5.8-rc kernels their console is spammed with 'bpfilter: write fail' messages [0]. Given this affected the 5.8 release and the fix was a one-line change, it felt appropriate to route it there. Why was a4fa458950b4 not pushed into bpf tree given it was affected there too? Either way, we can undo the double pos assignment upon tree sync.. [0] https://lore.kernel.org/lkml/20200727104636.nuz3u4xb7ba7ue5a@wittgenstein/