From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 827F235294E for ; Wed, 4 Mar 2026 15:59:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772639951; cv=none; b=DKqTZHxVfoCSxa7RzV0v0/mMx6AoLkCvAW0l9fxqKKIlpkm923CJqVRn4Ayjd+rBvReNfMcQhqJRdKMvZc2UWUuY/2Zjkq3xnG2t32WcMpW+E+U5g1NRAYwJ+ftsJb4u6EPvzdMWXphCHa1XXsEae9EWbOsPmGhdomtuNmMDySM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772639951; c=relaxed/simple; bh=sRkO7eLIQ3gUqOEx4ySJKyymRH2K2LfoKGh++9p0oBc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=heyB/Ecpw+ln6yhtST78qYVgec++0Sm2efsBj5Mht0PPnN8QJLxCaztCxtIbQgOxKMVE0Wz1qB7oZghx7fnnsBuap/7Z6zgR9P7n2uGuY6k5dhqAJu++DE/8WvCjQl8cHbLgoU69nteJfgln7y0/XSAUUfKhwN+RcdiOVmMPDgY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org; spf=none smtp.mailfrom=blackwall.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b=bCl7mpAT; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=blackwall.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=blackwall.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=blackwall.org header.i=@blackwall.org header.b="bCl7mpAT" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-48334ee0aeaso58829195e9.1 for ; Wed, 04 Mar 2026 07:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blackwall.org; s=google; t=1772639949; x=1773244749; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=HOSnZzfeSc3oCHq3PRnVd2F+xX7z1Nwp9tzlqrjRhhw=; b=bCl7mpATphtDitT/eSLxiEA6FtOIYGrpkTySJuJVnZiyRj41rVH10N6ylXXNJcoasi JuIc2+hmQ++Ja5/gsKlcal7/XTp+xh8nfblN5go2qu2QJLQeNVnJ4NXThFznSTlyl0We jTJ4oYxSdgPhhjrWcmBvZvZ/csYOhhTtSgkpX+qlwj0k1NCWQwO+2E7QrH56xXdsq3lx np5cNxcuPyXHDADxhrNVpJeKRU2VR5OK2WK51Q8JeGpZsQ4q6w6DstTeKZPVYN6G7lv8 cJdfsXJRot7b8jyykENAjFS3lFAIvPoMCDLB7H1wq3p+bynF/CRsfz682RXxQEsIIGv5 pA2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772639949; x=1773244749; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HOSnZzfeSc3oCHq3PRnVd2F+xX7z1Nwp9tzlqrjRhhw=; b=EyNBJGGSvrtVmIuvC2ybzQxPQG5QsIyvx+wIDwUUa+yitGAc5SM3v9SakdwMfl9UkS QTI9EbIrAMn6Hh6mI6CMHFwrk24b6bFoI2mA+zZxG0m5qxXEcFAERvzE+xTnGgp2PjtG Cb5Rn3YVoRGfxADSneKWMQR1VSdbfprMo2a5jG8W2ySZKb0E6yF6ly1ndhGcUGKxmxJa hllVQ4uGbtFsUr13l4tm29KFXGu8uHgYfJmXTmSQ1Xs3UxjujVuXLcEe1R2hFd72VkJW E9ZcHM27EXzlX0YRbGn/K1sDl6p0JSe5SSnu0ngpPBEY8F9ukyVmnYLpA2NE45e3rfEw TTkA== X-Forwarded-Encrypted: i=1; AJvYcCV/CTrPb8qd1IhaSDfziV6aAyt6AOaiZRyBROkv7p5qfpdIoI9zxjxM/s02RPR+stU0IqLoALCltpUEfms=@vger.kernel.org X-Gm-Message-State: AOJu0YzzINkizsEOo10bH6dRdmsvShXjw5Hx3nZFLXBhC7LFf/pKix6G p4Aa5la9qpEywtlQHuyOrlCnJV5ZjnVlUYRfgS+yXoTqKhBBunApSJzMa1I8elXehmE= X-Gm-Gg: ATEYQzzTVhlVBUcxcH6vsXZ0JCSHM7hhJKd0DA4hdLLErffS1TOjaMKnOTYfAHVBXU7 tBFOFMpYRFEukSiHSWxF2Y5xeA2CAJrk7GUjc6yVkhNaDR80tbMZR3j8bWKQJGszc7svlb2Zlav wQBnGQiaV2a7jE249ypW7VGd4u0EkA3jRAsUl3SOzpPDg51LYy2q3ItkQlDwMmMbGNFj/d/EfAY smtNKOMFZOadkC09xQAgcy+fxHHCxyr+WPGjI4NNwL8539bCyHbCx3hIb9gqb3VPaw4dfC1XY6o 1UppO3OpE58HrICZtcbXiWqqsyfRLCVvdk5xqG6X7Yw7uzZBR+lo7jXqHOVHuDK1cEBQ4nncJwY fBTyKqTN092liPqvJ1Brkl6HWRSrRIUvW8bplWoRalQJux8usiCRbZ4Yqz97tvi0Dc9BglnG3bU 3j7IhTEcQDfkjDjLyPsNtKA2UVK1bSxX6eTM+ZSm6YLliHYhvDa7eumdaTTA== X-Received: by 2002:a05:600c:3b29:b0:483:7980:4687 with SMTP id 5b1f17b1804b1-48519899381mr45743415e9.17.1772639948325; Wed, 04 Mar 2026 07:59:08 -0800 (PST) Received: from localhost (176.111.182.151.kyiv.nat.volia.net. [176.111.182.151]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4851acfa177sm21037355e9.4.2026.03.04.07.59.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Mar 2026 07:59:07 -0800 (PST) Date: Wed, 4 Mar 2026 17:59:06 +0200 From: Nikolay Aleksandrov To: Jiayuan Chen Cc: jv@jvosburgh.net, netdev@vger.kernel.org, jiayuan.chen@shopee.com, syzbot+80e046b8da2820b6ba73@syzkaller.appspotmail.com, Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , Stanislav Fomichev , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Shuah Khan , Sebastian Andrzej Siewior , Clark Williams , Steven Rostedt , Jussi Maki , linux-kernel@vger.kernel.org, bpf@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH net v4 1/2] bonding: fix null-ptr-deref in bond_rr_gen_slave_id() Message-ID: References: <20260304074301.35482-1-jiayuan.chen@linux.dev> <20260304074301.35482-2-jiayuan.chen@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260304074301.35482-2-jiayuan.chen@linux.dev> On Wed, Mar 04, 2026 at 03:42:57PM +0800, Jiayuan Chen wrote: > From: Jiayuan Chen > > bond_rr_gen_slave_id() dereferences bond->rr_tx_counter without a NULL > check. rr_tx_counter is a per-CPU counter only allocated in bond_open() > when the bond mode is round-robin. If the bond device was never brought > up, rr_tx_counter remains NULL, causing a null-ptr-deref. > > The XDP redirect path can reach this code even when the bond is not up: > bpf_master_redirect_enabled_key is a global static key, so when any bond > device has native XDP attached, the XDP_TX -> xdp_master_redirect() > interception is enabled for all bond slaves system-wide. This allows the > path xdp_master_redirect() -> bond_xdp_get_xmit_slave() -> > bond_xdp_xmit_roundrobin_slave_get() -> bond_rr_gen_slave_id() to be > reached on a bond that was never opened. > > Fix this by allocating rr_tx_counter unconditionally in bond_init() > (ndo_init), which is called by register_netdevice() and covers both > device creation paths (bond_create() and bond_newlink()). This also > handles the case where bond mode is changed to round-robin after device > creation. The conditional allocation in bond_open() is removed. Since > bond_destructor() already unconditionally calls > free_percpu(bond->rr_tx_counter), the lifecycle is clean: allocate at > ndo_init, free at destructor. > > Note: rr_tx_counter is only used by round-robin mode, so this > deliberately allocates a per-cpu u32 that goes unused for other modes. > Conditional allocation (e.g., in bond_option_mode_set) was considered > but rejected: the XDP path can race with mode changes on a downed bond, > and adding memory barriers to the XDP hot path is not justified for > saving 4 bytes per CPU. > > Fixes: 879af96ffd72 ("net, core: Add support for XDP redirection to slave device") > Reported-by: syzbot+80e046b8da2820b6ba73@syzkaller.appspotmail.com > Closes: https://lore.kernel.org/all/698f84c6.a70a0220.2c38d7.00cc.GAE@google.com/T/ > Signed-off-by: Jiayuan Chen > --- > drivers/net/bonding/bond_main.c | 19 +++++++++++++------ > 1 file changed, 13 insertions(+), 6 deletions(-) > IMO it's not worth it to waste memory in all modes, for an unpopular mode. I think it'd be better to add a null check in bond_rr_gen_slave_id(), READ/WRITE_ONCE() should be enough since it is allocated only once, and freed when the xmit code cannot be reachable anymore (otherwise we'd have more bugs now). The branch will be successfully predicted practically always, and you can also mark the ptr being null as unlikely. That way only RR takes a very minimal hit, if any. Cheers, Nik