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 5B218C678D5 for ; Tue, 7 Mar 2023 19:10:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233720AbjCGTKR (ORCPT ); Tue, 7 Mar 2023 14:10:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233696AbjCGTJl (ORCPT ); Tue, 7 Mar 2023 14:09:41 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC51E9AFE5 for ; Tue, 7 Mar 2023 10:54:34 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id s11so56415569edy.8 for ; Tue, 07 Mar 2023 10:54:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dectris.com; s=google; t=1678215266; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/VPBd1/cIEQ8mvitb5S4xC+5LiGWv+b4kdw/T6kpKD0=; b=Us2QhbUw+z3a2uMeUo1LJSWaebmcvd+wDCt5aYNo2hpwlTJSznm8XCZbQ/Hii9DzQK 0iODEn5ABEY6J5Hq5ltbknnHfB9rnPSWiFoI9H1QE2wFDEmc6nFqGD41YQWfyPXLvDZf 5wrFua3K05oDlr5QlF+zW6aXgF2AnFskagR24= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678215266; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/VPBd1/cIEQ8mvitb5S4xC+5LiGWv+b4kdw/T6kpKD0=; b=2pDk9pi5wcVGmdynXgalllzO1wWxcIFNKnt2DoYMkfY/QyI1bn1jMC2YtKT9KNFuHT cwzPi5zfZ7WtoDbZj1P77Vdfrm9wIPTq1mtmKCPWLJMXAZKfN+hSswDvrrxvNgAPfJin ZmGUEZVBW6qPKp6x/oqznJqXe4lWidvpYu2Q33G4NNCKJOZO8OaWJfYeutjUPvogz6RL M0K5UfCPdpd1UVxQn+5bgAQAqFrQTo5+szmsvwUnBIi8U8uic2u/5grjGtYIWJk0q4ed wMPi3WHoobFOyOUBqNu6XPyXM8YzZA1fL9CKxvvyHew8Yu79R1nfB2svePdIvh4q5Rp5 knIg== X-Gm-Message-State: AO0yUKUVvUA6cA7u6t+hBGTeD0wLVrQZ7IiKuMSrxOTwsnkvmDGCzWuh FYk4OolYuHa0QxKjtpIi3CilAImFLpXe5BNPeI0ERA== X-Google-Smtp-Source: AK7set85kBrN1ckdrgzPkzy2USMui/e5AnEbftp45IcxQYYItIX0J6t9Ki/qiu+re1+A5Mqm8btG1ezrj/FIr7l48Xo= X-Received: by 2002:a50:9fcd:0:b0:4ad:7389:d298 with SMTP id c71-20020a509fcd000000b004ad7389d298mr8543872edf.4.1678215266512; Tue, 07 Mar 2023 10:54:26 -0800 (PST) MIME-Version: 1.0 References: <20230307172306.786657-1-kal.conley@dectris.com> In-Reply-To: From: Kal Cutter Conley Date: Tue, 7 Mar 2023 19:58:51 +0100 Message-ID: Subject: Re: [PATCH] xsk: Add missing overflow check in xdp_umem_reg To: Alexander Lobakin Cc: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , netdev@vger.kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > The RCT declaration style is messed up in the whole block. Please move > lines around, there's nothing wrong in that. I think I figured out what this is. Is this preference documented somewhere? I will fix it. > > > int err; > > > > if (chunk_size < XDP_UMEM_MIN_CHUNK_SIZE || chunk_size > PAGE_SIZE) { > > @@ -188,8 +189,8 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr) > > if (npgs > U32_MAX) > > return -EINVAL; > > > > - chunks = (unsigned int)div_u64_rem(size, chunk_size, &chunks_rem); > > - if (chunks == 0) > > + chunks = div_u64_rem(size, chunk_size, &chunks_rem); > > + if (chunks == 0 || chunks > U32_MAX) > > You can change the first cond to `!chunks` while at it, it's more > preferred than `== 0`. If you want, I can change it. I generally like to keep unrelated changes to a minimum. > > > return -EINVAL; > > Do you have any particular bugs that the current code leads to? Or it's > just something that might hypothetically happen? If the UMEM is large enough, the code is broke. Maybe it can be exploited somehow? It should be checked for exactly the same reasons as `npgs` right above it. > > > > > if (!unaligned_chunks && chunks_rem) > > @@ -201,7 +202,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr) > > umem->size = size; > > umem->headroom = headroom; > > umem->chunk_size = chunk_size; > > - umem->chunks = chunks; > > + umem->chunks = (u32)chunks; > > You already checked @chunks fits into 32 bits, so the cast can be > omitted here, it's redundant. I made it consistent with the line right below it. It seems like the cast may improve readability since it makes it known the truncation is on purpose. I don't see how that is redundant with the safety check. Should I change both lines? > > > umem->npgs = (u32)npgs; > > umem->pgs = NULL; > > umem->user = NULL; > > Thanks, > Olek Kal