public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Xiang Mei <xmei5@asu.edu>
Cc: netdev@vger.kernel.org, jv@jvosburgh.net, andrew+netdev@lunn.ch,
	davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
	bestswngs@gmail.com
Subject: Re: [PATCH net] net: bonding: fix NULL deref in bond_debug_rlb_hash_show
Date: Mon, 16 Mar 2026 17:08:22 -0700	[thread overview]
Message-ID: <20260316170822.3e35122e@kernel.org> (raw)
In-Reply-To: <20260315194404.579122-1-xmei5@asu.edu>

On Sun, 15 Mar 2026 12:44:04 -0700 Xiang Mei wrote:
> rlb_clear_slave intentionally keeps RLB hash-table entries on
> the rx_hashtbl_used_head list with slave set to NULL when no
> replacement slave is available. However, bond_debug_rlb_hash_show
> visites client_info->slave without checking if it's NULL.
> 
> Other used-list iterators in bond_alb.c already handle this NULL-slave
> state safely:
> 
> - rlb_update_client returns early on !client_info->slave
> - rlb_req_update_slave_clients, rlb_clear_slave, and rlb_rebalance
> compare slave values before visiting
> - lb_req_update_subnet_clients continues if slave is NULL
> 
> The following NULL deref crash can be trigger in
> bond_debug_rlb_hash_show:
> 
> [    1.289791] BUG: kernel NULL pointer dereference, address: 0000000000000000
> [    1.290262] #PF: supervisor read access in kernel mode
> [    1.290494] #PF: error_code(0x0000) - not-present page
> [    1.290724] PGD 102a98067 P4D 102a98067 PUD 102831067 PMD 0
> [    1.291013] Oops: Oops: 0000 [#1] SMP NOPTI
> [    1.291202] CPU: 1 UID: 0 PID: 145 Comm: exploit Not tainted 7.0.0-rc3-virtme #1 PREEMPTLAZY
> [    1.291555] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.or4
> [    1.292058] RIP: 0010:bond_debug_rlb_hash_show (drivers/net/bonding/bond_debugfs.c:41)
> [    1.292286] Code: 83 fb ff 74 3c 48 c1 e3 06 49 03 9c 24 f0 00 00 00 48 c7 c6 d5 aa 9d 83 48 89 ef 48 8b 43 30 48 85

Please apply some critical thinking to the commit message.
Do you really think we need the code disasm for the second stack frame!?

Please trim the crash dump to what is relevant.
Around 20 lines of crucial stack trace and crash info.

Spend some time each day looking at submissions of expert developers.
-- 
pw-bot: cr

  parent reply	other threads:[~2026-03-17  0:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-15 19:44 [PATCH net] net: bonding: fix NULL deref in bond_debug_rlb_hash_show Xiang Mei
2026-03-15 19:49 ` Xiang Mei
2026-03-17  0:08 ` Jakub Kicinski [this message]
2026-03-17  0:54   ` Xiang Mei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260316170822.3e35122e@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=bestswngs@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jv@jvosburgh.net \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=xmei5@asu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox