Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp734085imm; Fri, 5 Oct 2018 10:49:40 -0700 (PDT) X-Google-Smtp-Source: ACcGV63WhCd4nOOA6dcKWDY3jTKSIyPV0fteu0fSQlZ+RBE05fHIDee5S25UgflRtvWSYLSz+2Yt X-Received: by 2002:a63:cd45:: with SMTP id a5-v6mr11326764pgj.43.1538761780391; Fri, 05 Oct 2018 10:49:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538761780; cv=none; d=google.com; s=arc-20160816; b=I3oEnoZGFEP0+giTQu3i4C0JK1T8Xw05imsNHhKSolnCFyjA+D4c1W0E4pG/TUkbRH X5F7aDLdwKQxETnDWvkxesRQswDKisyM0mwUGSFHt4tXumLUxab/FH1IzkOeBZhNVsha GzF6KA28W6L3J6YXFxpD0ZaksNYVY6CsM6r4e5Stz1f/3cc3KHoZSttzJFFZgNyxm9hX LMykEfZBskx/UZHD34OQgsAycUTmwG4g1Is+9WY6VffrdLYjr8xAWasNltL1c2XZbM2N sjAc/2BXHjqzOFAy2LUlAa64WqKkTXmD6N9WJgfkFyfqabtuDDVtiVBcor+IgStozlzn 83iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=0nSvjcdd+n4ZxbqkLJQfNkXVqRv7Rd2ob5gTNoO8xkg=; b=rY1SX3eDA6A5BBzSTWUJaadu405Sm1ksAfhbGeb1Rkdb22G7Lda+hESjKEPqWSUqXz KRUHJOLbSD01D0IbbmvERY5L7GJID8XK5/zueQvdU4MIQvuSiBhacBFzPUa7zEgKBO9l SnXivPL16hxdG4CfRU4/RKN/ENoRkGBaQSVoJ1Pe3h2jty+oRIhU4/P+esa+by/cXVDs TTuoGsONuepNlA88qmbdsGRaDO+b0zeWNU215ZzdP6Xk8WRuy8dIZBZWcRDDoc7ywHz0 t42gQjn3Lce2ovKZ6cbb8DyJE1TAMdlUInEXDcph5IjB1B/ly9q5Py3EPDD8sWr5NOR6 3/nw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x5-v6si8662465pgc.210.2018.10.05.10.49.25; Fri, 05 Oct 2018 10:49:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728916AbeJFArr (ORCPT + 99 others); Fri, 5 Oct 2018 20:47:47 -0400 Received: from www62.your-server.de ([213.133.104.62]:57006 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727941AbeJFArr (ORCPT ); Fri, 5 Oct 2018 20:47:47 -0400 Received: from [78.46.172.3] (helo=sslproxy06.your-server.de) by www62.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1g8UCk-00033a-TT; Fri, 05 Oct 2018 19:47:58 +0200 Received: from [62.203.87.61] (helo=linux.home) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1g8UCk-000X0M-OY; Fri, 05 Oct 2018 19:47:58 +0200 Subject: Re: [PATCH] bpf: 32-bit RSH verification must truncate input before the ALU op To: Jann Horn , Alexei Starovoitov , netdev@vger.kernel.org Cc: "David S. Miller" , linux-kernel@vger.kernel.org References: <20181005161759.177992-1-jannh@google.com> From: Daniel Borkmann Message-ID: Date: Fri, 5 Oct 2018 19:47:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20181005161759.177992-1-jannh@google.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.100.1/25009/Fri Oct 5 14:48:12 2018) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/05/2018 06:17 PM, Jann Horn wrote: > When I wrote commit 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification"), I > assumed that, in order to emulate 64-bit arithmetic with 32-bit logic, it > is sufficient to just truncate the output to 32 bits; and so I just moved > the register size coercion that used to be at the start of the function to > the end of the function. > > That assumption is true for almost every op, but not for 32-bit right > shifts, because those can propagate information towards the least > significant bit. Fix it by always truncating inputs for 32-bit ops to 32 > bits. > > Also get rid of the coerce_reg_to_size() after the ALU op, since that has > no effect. > > Fixes: 468f6eafa6c4 ("bpf: fix 32-bit ALU op verification") > Acked-by: Daniel Borkmann > Signed-off-by: Jann Horn Applied to bpf, thanks Jann!