[PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[Yunseong Kim]

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit e9acda5 ]

Fix a use-after-free which happens due to enslave failure after the new
slave has been added to the array. Since the new slave can be used for Tx
immediately, we can use it after it has been freed by the enslave error
cleanup path which frees the allocated slave memory. Slave update array is
supposed to be called last when further enslave failures are not expected.
Move it after xdp setup to avoid any problems.

It is very easy to reproduce the problem with a simple xdp_pass prog:
 ip l add bond1 type bond mode balance-xor
 ip l set bond1 up
 ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass
 ip l add dumdum type dummy

Then run in parallel:
 while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done;
 mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"

The crash happens almost immediately:
 [  605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI
 [  605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]
 [  605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G    B               6.19.0-rc6+ #21 PREEMPT(voluntary)
 [  605.602979] Tainted: [B]=BAD_PAGE
 [  605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
 [  605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210
 [  605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89
 [  605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213
 [  605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000
 [  605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be
 [  605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c
 [  605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000
 [  605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84
 [  605.603286] FS:  00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000
 [  605.603319] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 [  605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0
 [  605.603373] Call Trace:
 [  605.603392]  <TASK>
 [  605.603410]  __dev_queue_xmit+0x448/0x32a0
 [  605.603434]  ? __pfx_vprintk_emit+0x10/0x10
 [  605.603461]  ? __pfx_vprintk_emit+0x10/0x10
 [  605.603484]  ? __pfx___dev_queue_xmit+0x10/0x10
 [  605.603507]  ? bond_start_xmit+0xbfb/0xc20 [bonding]
 [  605.603546]  ? _printk+0xcb/0x100
 [  605.603566]  ? __pfx__printk+0x10/0x10
 [  605.603589]  ? bond_start_xmit+0xbfb/0xc20 [bonding]
 [  605.603627]  ? add_taint+0x5e/0x70
 [  605.603648]  ? add_taint+0x2a/0x70
 [  605.603670]  ? end_report.cold+0x51/0x75
 [  605.603693]  ? bond_start_xmit+0xbfb/0xc20 [bonding]
 [  605.603731]  bond_start_xmit+0x623/0xc20 [bonding]

Fixes: 9e2ee5c7e7c3 ("net, bonding: Add XDP support to the bonding driver")
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reported-by: Chen Zhen <chenzhen126@huawei.com>
Closes: https://lore.kernel.org/netdev/fae17c21-4940-5605-85b2-1d5e17342358@huawei.com/
CC: Jussi Maki <joamaki@gmail.com>
CC: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://patch.msgid.link/20260123120659.571187-1-razor@blackwall.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tested-by: Yunseong Kim <yunseong.kim@est.tech>
Signed-off-by: Yunseong Kim <yunseong.kim@est.tech>
---
 drivers/net/bonding/bond_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 5035cfa74f1a..0858116687b4 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2349,9 +2349,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
 		unblock_netpoll_tx();
 	}
 
-	if (bond_mode_can_use_xmit_hash(bond))
-		bond_update_slave_arr(bond, NULL);
-
 	if (!slave_dev->netdev_ops->ndo_bpf ||
 	    !slave_dev->netdev_ops->ndo_xdp_xmit) {
 		if (bond->xdp_prog) {
@@ -2385,6 +2382,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev,
 			bpf_prog_inc(bond->xdp_prog);
 	}
 
+	if (bond_mode_can_use_xmit_hash(bond))
+		bond_update_slave_arr(bond, NULL);
+
 	bond_xdp_set_features(bond_dev);
 
 	slave_info(bond_dev, slave_dev, "Enslaving as %s interface with %s link\n",
-- 
2.53.0

Re: [PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[Greg KH]

On Sun, Apr 26, 2026 at 10:12:05PM +0200, Yunseong Kim wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

I did NOT write this commit.

> [ Upstream commit e9acda5 ]

Please use the full commit id.  And get the authorship right :)

thanks,

greg k-h

Re: [PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[Yunseong Kim]

Hi Greg,

On 5/4/26 14:05, Greg KH wrote:
> On Sun, Apr 26, 2026 at 10:12:05PM +0200, Yunseong Kim wrote:
>> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> I did NOT write this commit.
> 
>> [ Upstream commit e9acda5 ]
> 
> Please use the full commit id.  And get the authorship right :)
> 
> thanks,
> 
> greg k-h


Thank you for the code review. I’ll fix it and send a v2.

Additionally, last week I submitted a few patches to the checkpatch.pl
script—currently, all backport tags(following stable kernel rules
Option 3) using <sha1 40 length> pattern are triggering false positives:

  https://lore.kernel.org/lkml/20260505112320.362715-2-yunseong.kim@est.tech/

Best regards,
Yunseong

Re: [PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[Greg KH]

On Tue, May 05, 2026 at 12:30:48PM +0000, Yunseong Kim wrote:
> Hi Greg,
> 
> On 5/4/26 14:05, Greg KH wrote:
> > On Sun, Apr 26, 2026 at 10:12:05PM +0200, Yunseong Kim wrote:
> >> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > 
> > I did NOT write this commit.
> > 
> >> [ Upstream commit e9acda5 ]
> > 
> > Please use the full commit id.  And get the authorship right :)
> > 
> > thanks,
> > 
> > greg k-h
> 
> 
> Thank you for the code review. I’ll fix it and send a v2.
> 
> Additionally, last week I submitted a few patches to the checkpatch.pl
> script—currently, all backport tags(following stable kernel rules
> Option 3) using <sha1 40 length> pattern are triggering false positives:
> 
>   https://lore.kernel.org/lkml/20260505112320.362715-2-yunseong.kim@est.tech/

Checkpatch should not be needed to be run on stable kernel backports, so
I don't really think that is necessary.

thanks,

greg k-h

Re: [PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[Yunseong Kim]

Hi Greg,

On 5/5/26 14:35, Greg KH wrote:
> On Tue, May 05, 2026 at 12:30:48PM +0000, Yunseong Kim wrote:
>> Hi Greg,
>>
>> On 5/4/26 14:05, Greg KH wrote:
>>> On Sun, Apr 26, 2026 at 10:12:05PM +0200, Yunseong Kim wrote:
>>>> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>
>>> I did NOT write this commit.
>>>
>>>> [ Upstream commit e9acda5 ]
>>>
>>> Please use the full commit id.  And get the authorship right :)
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>>
>> Thank you for the code review. I’ll fix it and send a v2.
>>
>> Additionally, last week I submitted a few patches to the checkpatch.pl
>> script—currently, all backport tags(following stable kernel rules
>> Option 3) using <sha1 40 length> pattern are triggering false positives:
>>
>>   https://lore.kernel.org/lkml/20260505112320.362715-2-yunseong.kim@est.tech/
> 
> Checkpatch should not be needed to be run on stable kernel backports, so
> I don't really think that is necessary.
> 
> thanks,
> 
> greg k-h

While reading Documentation/process/stable-kernel-rules.rst, I noticed that
it doesn't explicitly mention the requirement for a full 40-character SHA-1 or
the whether to use of checkpatch.pl for validation.

Would it be good to adding these rule to the documentation? I believe            
formalizing this could help contributors(like me :)) submit more accurate                  
backport and reduce the need for manual corrections.

Thank you again.

Best regards,
Yunseong

Re: [PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[Greg KH]

On Tue, May 05, 2026 at 12:52:34PM +0000, Yunseong Kim wrote:
> Hi Greg,
> 
> On 5/5/26 14:35, Greg KH wrote:
> > On Tue, May 05, 2026 at 12:30:48PM +0000, Yunseong Kim wrote:
> >> Hi Greg,
> >>
> >> On 5/4/26 14:05, Greg KH wrote:
> >>> On Sun, Apr 26, 2026 at 10:12:05PM +0200, Yunseong Kim wrote:
> >>>> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>>
> >>> I did NOT write this commit.
> >>>
> >>>> [ Upstream commit e9acda5 ]
> >>>
> >>> Please use the full commit id.  And get the authorship right :)
> >>>
> >>> thanks,
> >>>
> >>> greg k-h
> >>
> >>
> >> Thank you for the code review. I’ll fix it and send a v2.
> >>
> >> Additionally, last week I submitted a few patches to the checkpatch.pl
> >> script—currently, all backport tags(following stable kernel rules
> >> Option 3) using <sha1 40 length> pattern are triggering false positives:
> >>
> >>   https://lore.kernel.org/lkml/20260505112320.362715-2-yunseong.kim@est.tech/
> > 
> > Checkpatch should not be needed to be run on stable kernel backports, so
> > I don't really think that is necessary.
> > 
> > thanks,
> > 
> > greg k-h
> 
> While reading Documentation/process/stable-kernel-rules.rst, I noticed that
> it doesn't explicitly mention the requirement for a full 40-character SHA-1 or
> the whether to use of checkpatch.pl for validation.

That's fine.

> Would it be good to adding these rule to the documentation? I believe            
> formalizing this could help contributors(like me :)) submit more accurate                  
> backport and reduce the need for manual corrections.

When you get a FAILED email, it provides full information on how to
create a backported patch.  is that list not sufficient?

thanks,

greg k-h

Re: [PATCH 6.12.y] bonding: fix use-after-free due to enslave fail after slave array update

[Yunseong Kim]

Thank you Greg,

On 5/5/26 15:04, Greg KH wrote:
> On Tue, May 05, 2026 at 12:52:34PM +0000, Yunseong Kim wrote:
>> Hi Greg,
>>
>> On 5/5/26 14:35, Greg KH wrote:
>>> On Tue, May 05, 2026 at 12:30:48PM +0000, Yunseong Kim wrote:
>>>> Hi Greg,
>>>>
>>>> On 5/4/26 14:05, Greg KH wrote:
>>>>> On Sun, Apr 26, 2026 at 10:12:05PM +0200, Yunseong Kim wrote:
>>>>>> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>>
>>>>> I did NOT write this commit.
>>>>>
>>>>>> [ Upstream commit e9acda5 ]
>>>>>
>>>>> Please use the full commit id.  And get the authorship right :)
>>>>>
>>>>> thanks,
>>>>>
>>>>> greg k-h
>>>>
>>>>
>>>> Thank you for the code review. I’ll fix it and send a v2.
>>>>
>>>> Additionally, last week I submitted a few patches to the checkpatch.pl
>>>> script—currently, all backport tags(following stable kernel rules
>>>> Option 3) using <sha1 40 length> pattern are triggering false positives:
>>>>
>>>>   https://lore.kernel.org/lkml/20260505112320.362715-2-yunseong.kim@est.tech/
>>>
>>> Checkpatch should not be needed to be run on stable kernel backports, so
>>> I don't really think that is necessary.
>>>
>>> thanks,
>>>
>>> greg k-h
>>
>> While reading Documentation/process/stable-kernel-rules.rst, I noticed that
>> it doesn't explicitly mention the requirement for a full 40-character SHA-1 or
>> the whether to use of checkpatch.pl for validation.
> 
> That's fine.
> 
>> Would it be good to adding these rule to the documentation? I believe            
>> formalizing this could help contributors(like me :)) submit more accurate                  
>> backport and reduce the need for manual corrections.
> 
> When you get a FAILED email, it provides full information on how to
> create a backported patch.  is that list not sufficient?

Thanks for the feedback. It is really helpful. You're right. the information
provided in the emails is sufficient. I'll make sure to follow those
instructions more carefully for future backports work.

> thanks,
> 
> greg k-h

I appreciate you taking the time to clarify.

Best regards,
Yunseong