mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Waiman Long <longman@redhat.com>
To: Xingyu Li <xli399@ucr.edu>,
	peterz@infradead.org, mingo@redhat.com, will@kernel.org,
	boqun.feng@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: BUG: general protection fault in kernfs_remove_by_name_ns
Date: Sun, 25 Aug 2024 11:43:54 -0400	[thread overview]
Message-ID: <067963b0-17be-4c4d-8485-a49cfe9da5fb@redhat.com> (raw)
In-Reply-To: <CALAgD-6=bRtF++chjMwgTyMssCqyPzhXyY=zjB6w5SorVxuCcw@mail.gmail.com>

On 8/25/24 00:53, Xingyu Li wrote:
> Hi,
>
> We found a bug in linux 6.10. It is probably a null pointer dereference bug.
> The bug report is as follows, but unfortunately there is no generated
> syzkaller reproducer.
>
> netdevsim netdevsim0 netdevsim2 (unregistering): unset [1, 0] type 2
> family 0 port 6081 - 0
> netdevsim netdevsim0 netdevsim1 (unregistering): unset [1, 0] type 2
> family 0 port 6081 - 0
> netdevsim netdevsim0 netdevsim0 (unregistering): unset [1, 0] type 2
> family 0 port 6081 - 0
> Oops: general protection fault, probably for non-canonical address
> 0xdffffc0000000029: 0000 [#1] PREEMPT SMP KASAN PTI
> KASAN: null-ptr-deref in range [0x0000000000000148-0x000000000000014f]
> CPU: 0 PID: 10054 Comm: kworker/u4:29 Not tainted 6.10.0 #13
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> Workqueue: netns cleanup_net
> RIP: 0010:__lock_acquire+0x106/0x8050 kernel/locking/lockdep.c:5005
> Code: 85 5d 20 00 00 83 3d 14 d2 b5 0d 00 48 89 9c 24 18 01 00 00 0f
> 84 00 10 00 00 83 3d 33 3a 31 0c 00 74 31 48 89 d0 48 c1 e8 03 <42> 80
> 3c 00 00 74 17 48 89 d7 e8 fb 9c 85 00 48 8b 54 24 10 49 b8
> RSP: 0018:ffffc9000a0bf540 EFLAGS: 00010002
> RAX: 0000000000000029 RBX: 1ffff92001417ecc RCX: 0000000000000000
> RDX: 0000000000000148 RSI: 0000000000000000 RDI: 0000000000000148
> RBP: ffffc9000a0bf808 R08: dffffc0000000000 R09: 0000000000000000
> R10: dffffc0000000000 R11: fffffbfff1e48be6 R12: 0000000000000001
> R13: 0000000000000000 R14: 0000000000000000 R15: ffff88801fc31e00
> FS:  0000000000000000(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fc6fba84cd0 CR3: 0000000020224000 CR4: 0000000000350ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   <TASK>
>   lock_acquire+0x1a9/0x400 kernel/locking/lockdep.c:5754
>   down_write+0x36/0x50 kernel/locking/rwsem.c:1579
>   kernfs_remove_by_name_ns+0x76/0x150 fs/kernfs/dir.c:1689
>   del_nbp+0xa6/0xb50 net/bridge/br_if.c:338
>   br_dev_delete+0x76/0x110 net/bridge/br_if.c:386
>   br_net_exit_batch_rtnl+0xee/0x1a0 net/bridge/br.c:369
>   cleanup_net+0x712/0xcd0 net/core/net_namespace.c:633
>   process_one_work kernel/workqueue.c:3248 [inline]
>   process_scheduled_works+0x977/0x1410 kernel/workqueue.c:3329
>   worker_thread+0xaa0/0x1020 kernel/workqueue.c:3409
>   kthread+0x2eb/0x380 kernel/kthread.c:389
>   ret_from_fork+0x49/0x80 arch/x86/kernel/process.c:147
>   ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:244
>   </TASK>

I don't believe it is a bug in the locking code.

> RIP: 0010:__lock_acquire+0x106/0x8050 kernel/locking/lockdep.c:5005

5005         if (!prove_locking || lock->key == &__lockdep_no_validate__)

This crash is likely caused by passing in an incorrect rw_semaphore pointer.

> kernfs_remove_by_name_ns+0x76/0x150 fs/kernfs/dir.c:1689

1676 int kernfs_remove_by_name_ns(struct kernfs_node *parent, const char 
*name,
1677                              const void *ns)
1678 {
   :
1688         root = kernfs_root(parent);
1689         down_write(&root->kernfs_rwsem);

> del_nbp+0xa6/0xb50 net/bridge/br_if.c:338

333 static void del_nbp(struct net_bridge_port *p)
334 {
335         struct net_bridge *br = p->br;
336         struct net_device *dev = p->dev;
337

338         sysfs_remove_link(br->ifobj, p->dev->name);

ETHERNET BRIDGE
M:      Roopa Prabhu <roopa@nvidia.com>
M:      Nikolay Aleksandrov <razor@blackwall.org>
L:      bridge@lists.linux.dev
L:      netdev@vger.kernel.org
S:      Maintained
W:      http://www.linuxfoundation.org/en/Net:Bridge
F:      include/linux/netfilter_bridge/
F:      net/bridge/

I would suggest you report this issue to the maintainers to the ethernet 
bridge component first.

Cheers,
Longman



      reply	other threads:[~2024-08-25 15:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-25  4:53 Xingyu Li
2024-08-25 15:43 ` Waiman Long [this message]

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=067963b0-17be-4c4d-8485-a49cfe9da5fb@redhat.com \
    --to=longman@redhat.com \
    --cc=boqun.feng@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    --cc=xli399@ucr.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

all inboxes | Powered by JetHome®