netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hangbin Liu <liuhangbin@gmail.com>
To: Nikolay Aleksandrov <razor@blackwall.org>
Cc: netdev@vger.kernel.org, Taehee Yoo <ap420073@gmail.com>,
	davem@davemloft.net, jv@jvosburgh.net, andy@greyhouse.net,
	edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
	jarod@redhat.com
Subject: Re: [PATCH net 2/4] bonding: fix null pointer deref in bond_ipsec_offload_ok
Date: Mon, 19 Aug 2024 16:12:25 +0800	[thread overview]
Message-ID: <ZsL-aVPLJ1EmM53y@Laptop-X1> (raw)
In-Reply-To: <a8ebc617-dc20-4803-9332-246d54ccf8d8@blackwall.org>

On Mon, Aug 19, 2024 at 10:25:37AM +0300, Nikolay Aleksandrov wrote:
> On 19/08/2024 05:53, Hangbin Liu wrote:
> > On Fri, Aug 16, 2024 at 02:48:11PM +0300, Nikolay Aleksandrov wrote:
> >> We must check if there is an active slave before dereferencing the pointer.
> >>
> >> Fixes: 18cb261afd7b ("bonding: support hardware encryption offload to slaves")
> >> Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
> >> ---
> >>  drivers/net/bonding/bond_main.c | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> >> index 85b5868deeea..65ddb71eebcd 100644
> >> --- a/drivers/net/bonding/bond_main.c
> >> +++ b/drivers/net/bonding/bond_main.c
> >> @@ -604,6 +604,8 @@ static bool bond_ipsec_offload_ok(struct sk_buff *skb, struct xfrm_state *xs)
> >>  	bond = netdev_priv(bond_dev);
> >>  	rcu_read_lock();
> >>  	curr_active = rcu_dereference(bond->curr_active_slave);
> >> +	if (!curr_active)
> >> +		goto out;
> >>  	real_dev = curr_active->dev;
> >>  
> >>  	if (BOND_MODE(bond) != BOND_MODE_ACTIVEBACKUP)
> >> -- 
> >> 2.44.0
> >>
> > 
> > BTW, the bond_ipsec_offload_ok() only checks !xs->xso.real_dev, should we also
> > add WARN_ON(xs->xso.real_dev != slave->dev) checking?
> > 
> > Thanks
> > Hangbin
> 
> We could, but not a warn_on() because I bet it can be easily triggered
> by changing the active slave in parallel. real_dev is read without a

OK, maybe a pr_warn or salve_warn()?

> lock here so we cannot guarantee a sane state if policies are changed
> under us. I think the callback should handle it by checking that the
> new device doesn't have the policy setup yet, because the case happens
> when an active slave changes which means policies are about to be
> installed on the new one.

Hmm, how to check if a device has policy setup except ipsec->xs->xso.real_dev?

Hangbin

  reply	other threads:[~2024-08-19  8:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16 11:48 [PATCH net 0/4] bonding: fix xfrm offload bugs Nikolay Aleksandrov
2024-08-16 11:48 ` [PATCH net 1/4] bonding: fix bond_ipsec_offload_ok return type Nikolay Aleksandrov
2024-08-19  2:43   ` Hangbin Liu
2024-08-16 11:48 ` [PATCH net 2/4] bonding: fix null pointer deref in bond_ipsec_offload_ok Nikolay Aleksandrov
2024-08-19  2:45   ` Hangbin Liu
2024-08-19  2:53   ` Hangbin Liu
2024-08-19  7:25     ` Nikolay Aleksandrov
2024-08-19  8:12       ` Hangbin Liu [this message]
2024-08-19  7:26   ` Eric Dumazet
2024-08-16 11:48 ` [PATCH net 3/4] bonding: fix xfrm real_dev null pointer dereference Nikolay Aleksandrov
2024-08-19  2:54   ` Hangbin Liu
2024-08-19  7:34     ` Nikolay Aleksandrov
2024-08-19  8:25       ` Nikolay Aleksandrov
2024-08-19  8:34       ` Hangbin Liu
2024-08-16 11:48 ` [PATCH net 4/4] bonding: fix xfrm state handling when clearing active slave Nikolay Aleksandrov
2024-08-19  3:05   ` Hangbin Liu
2024-08-19  7:38     ` Nikolay Aleksandrov
2024-08-20  3:48       ` Hangbin Liu
2024-08-16 11:52 ` [PATCH net 0/4] bonding: fix xfrm offload bugs Nikolay Aleksandrov
2024-08-20 13:40 ` patchwork-bot+netdevbpf

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=ZsL-aVPLJ1EmM53y@Laptop-X1 \
    --to=liuhangbin@gmail.com \
    --cc=andy@greyhouse.net \
    --cc=ap420073@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=jarod@redhat.com \
    --cc=jv@jvosburgh.net \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=razor@blackwall.org \
    /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;
as well as URLs for NNTP newsgroup(s).