* [PATCH] configfs: fix refcount warning in configfs_get_config_item() @ 2026-07-29 8:55 Joshua Crofts 2026-07-29 9:00 ` Joshua Crofts 2026-07-29 10:06 ` Breno Leitao 0 siblings, 2 replies; 7+ messages in thread From: Joshua Crofts @ 2026-07-29 8:55 UTC (permalink / raw) To: Andreas Hindborg, Breno Leitao; +Cc: linux-kernel, syzbot+35790eb7861f8fc57382 syzbot reported a "refcount_t: addition on 0; use-after-free" warning in configfs_get_config_item(). This occurs when configfs_get_config_item() races with a concurrent teardown (e.g. rmdir). When the target config_item's refcount drops to 0, configfs_get_config_item() calls config_item_get(), which unconditionally increments the refcount via kref_get(), triggering the refcount warning. Fix this by using config_item_get_unless_zero(), which safely returns NULL if the refcount is already 0. Reported-by: syzbot+35790eb7861f8fc57382@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=35790eb7861f8fc57382 Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> --- fs/configfs/configfs_internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h index acdeea8e2..5448af3a8 100644 --- a/fs/configfs/configfs_internal.h +++ b/fs/configfs/configfs_internal.h @@ -124,7 +124,7 @@ static inline struct config_item *configfs_get_config_item(struct dentry *dentry spin_lock(&dentry->d_lock); if (!d_unhashed(dentry)) { struct configfs_dirent * sd = dentry->d_fsdata; - item = config_item_get(sd->s_element); + item = config_item_get_unless_zero(sd->s_element); } spin_unlock(&dentry->d_lock); -- 2.47.3 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item() 2026-07-29 8:55 [PATCH] configfs: fix refcount warning in configfs_get_config_item() Joshua Crofts @ 2026-07-29 9:00 ` Joshua Crofts 2026-07-29 9:51 ` Jeffin Philip 2026-07-29 10:06 ` Breno Leitao 1 sibling, 1 reply; 7+ messages in thread From: Joshua Crofts @ 2026-07-29 9:00 UTC (permalink / raw) To: Andreas Hindborg, Breno Leitao; +Cc: linux-kernel, syzbot+35790eb7861f8fc57382 On Wed, 29 Jul 2026 08:55:05 +0000 Joshua Crofts <joshua.crofts1@gmail.com> wrote: > syzbot reported a "refcount_t: addition on 0; use-after-free" warning > in configfs_get_config_item(). > > This occurs when configfs_get_config_item() races with a concurrent > teardown (e.g. rmdir). When the target config_item's refcount drops to > 0, configfs_get_config_item() calls config_item_get(), which > unconditionally increments the refcount via kref_get(), triggering the > refcount warning. > > Fix this by using config_item_get_unless_zero(), which safely returns > NULL if the refcount is already 0. > > Reported-by: syzbot+35790eb7861f8fc57382@syzkaller.appspotmail.com > Closes: https://syzkaller.appspot.com/bug?extid=35790eb7861f8fc57382 > Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> > --- > fs/configfs/configfs_internal.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h > index acdeea8e2..5448af3a8 100644 > --- a/fs/configfs/configfs_internal.h > +++ b/fs/configfs/configfs_internal.h > @@ -124,7 +124,7 @@ static inline struct config_item *configfs_get_config_item(struct dentry *dentry > spin_lock(&dentry->d_lock); > if (!d_unhashed(dentry)) { > struct configfs_dirent * sd = dentry->d_fsdata; > - item = config_item_get(sd->s_element); > + item = config_item_get_unless_zero(sd->s_element); > } > spin_unlock(&dentry->d_lock); > Forgot to add a Fixes: tag so here it is, will respin if necessary: Fixes: e9c03af21cc7 ("configfs: calculate the symlink target only once") -- Kind regards, Joshua Crofts ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item() 2026-07-29 9:00 ` Joshua Crofts @ 2026-07-29 9:51 ` Jeffin Philip 2026-07-29 13:50 ` Joshua Crofts 0 siblings, 1 reply; 7+ messages in thread From: Jeffin Philip @ 2026-07-29 9:51 UTC (permalink / raw) To: joshua.crofts1 Cc: a.hindborg, leitao, linux-kernel, syzbot+35790eb7861f8fc57382, Jeffin Philip On Wed, 29 Jul 2026 09:00 +0000 Joshua Crofts <joshua.crofts1@gmail.com> wrote: >On Wed, 29 Jul 2026 08:55:05 +0000 >Joshua Crofts <joshua.crofts1@gmail.com> wrote: > >> syzbot reported a "refcount_t: addition on 0; use-after-free" warning >> in configfs_get_config_item(). >> >> This occurs when configfs_get_config_item() races with a concurrent >> teardown (e.g. rmdir). When the target config_item's refcount drops to >> 0, configfs_get_config_item() calls config_item_get(), which >> unconditionally increments the refcount via kref_get(), triggering the >> refcount warning. >> >> Fix this by using config_item_get_unless_zero(), which safely returns >> NULL if the refcount is already 0. >> Reported-by: syzbot+35790eb7861f8fc57382@syzkaller.appspotmail.com >> Closes: https://syzkaller.appspot.com/bug?extid=35790eb7861f8fc57382 >> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> >> --- >> fs/configfs/configfs_internal.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h >> index acdeea8e2..5448af3a8 100644 >> --- a/fs/configfs/configfs_internal.h >> +++ b/fs/configfs/configfs_internal.h >> @@ -124,7 +124,7 @@ static inline struct config_item *configfs_get_config_item(struct dentry *dentry >> spin_lock(&dentry->d_lock); >> if (!d_unhashed(dentry)) { >> struct configfs_dirent * sd = dentry->d_fsdata; >> - item = config_item_get(sd->s_element); >> + item = config_item_get_unless_zero(sd->s_element); >> } >> spin_unlock(&dentry->d_lock); I tested this solution first on syzbot and well, it errored out. But on testing it on a local build, it seems to trigger a different warning in configfs_get() regarding atomic count. Could you please look into it? Thanks, Jeffin. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item() 2026-07-29 9:51 ` Jeffin Philip @ 2026-07-29 13:50 ` Joshua Crofts 0 siblings, 0 replies; 7+ messages in thread From: Joshua Crofts @ 2026-07-29 13:50 UTC (permalink / raw) To: Jeffin Philip Cc: a.hindborg, leitao, linux-kernel, syzbot+35790eb7861f8fc57382 On Wed, 29 Jul 2026 15:21:25 +0530 Jeffin Philip <jeffinphilip14@gmail.com> wrote: > On Wed, 29 Jul 2026 09:00 +0000 > Joshua Crofts <joshua.crofts1@gmail.com> wrote: > > >On Wed, 29 Jul 2026 08:55:05 +0000 > >Joshua Crofts <joshua.crofts1@gmail.com> wrote: > > > >> syzbot reported a "refcount_t: addition on 0; use-after-free" warning > >> in configfs_get_config_item(). > >> > >> This occurs when configfs_get_config_item() races with a concurrent > >> teardown (e.g. rmdir). When the target config_item's refcount drops to > >> 0, configfs_get_config_item() calls config_item_get(), which > >> unconditionally increments the refcount via kref_get(), triggering the > >> refcount warning. > >> > >> Fix this by using config_item_get_unless_zero(), which safely returns > >> NULL if the refcount is already 0. > >> Reported-by: syzbot+35790eb7861f8fc57382@syzkaller.appspotmail.com > >> Closes: https://syzkaller.appspot.com/bug?extid=35790eb7861f8fc57382 > >> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> > >> --- > >> fs/configfs/configfs_internal.h | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h > >> index acdeea8e2..5448af3a8 100644 > >> --- a/fs/configfs/configfs_internal.h > >> +++ b/fs/configfs/configfs_internal.h > >> @@ -124,7 +124,7 @@ static inline struct config_item *configfs_get_config_item(struct dentry *dentry > >> spin_lock(&dentry->d_lock); > >> if (!d_unhashed(dentry)) { > >> struct configfs_dirent * sd = dentry->d_fsdata; > >> - item = config_item_get(sd->s_element); > >> + item = config_item_get_unless_zero(sd->s_element); > >> } > >> spin_unlock(&dentry->d_lock); > > I tested this solution first on syzbot and well, it errored out. But on testing it on a local > build, it seems to trigger a different warning in configfs_get() regarding atomic count. Could you please > look into it? Yeah, I've no idea why syzbot keeps failing on "FATAL: Kernel too old", especially when testing against upstream. As for the different warning, that's odd, because when I booted the kernel with the patch in QEMU and ran the reproducer nothing happened. Could you please send the warning in it's entirety? -- Kind regards, Joshua Crofts ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item() 2026-07-29 8:55 [PATCH] configfs: fix refcount warning in configfs_get_config_item() Joshua Crofts 2026-07-29 9:00 ` Joshua Crofts @ 2026-07-29 10:06 ` Breno Leitao 2026-07-29 13:31 ` Joshua Crofts 1 sibling, 1 reply; 7+ messages in thread From: Breno Leitao @ 2026-07-29 10:06 UTC (permalink / raw) To: Joshua Crofts; +Cc: Andreas Hindborg, linux-kernel, syzbot+35790eb7861f8fc57382 On Wed, Jul 29, 2026 at 08:55:05AM +0000, Joshua Crofts wrote: > syzbot reported a "refcount_t: addition on 0; use-after-free" warning > in configfs_get_config_item(). > > This occurs when configfs_get_config_item() races with a concurrent > teardown (e.g. rmdir). When the target config_item's refcount drops to > 0, configfs_get_config_item() calls config_item_get(), which > unconditionally increments the refcount via kref_get(), triggering the > refcount warning. Shouldn't be this the fix we are interested in fixing? > Fix this by using config_item_get_unless_zero(), which safely returns > NULL if the refcount is already 0. This looks like more a workaround than a proper fix, no? I got the impression that we have a UAF behind this refcount issue, and this is not being solved by this patch. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item() 2026-07-29 10:06 ` Breno Leitao @ 2026-07-29 13:31 ` Joshua Crofts 2026-07-29 15:05 ` Jeffin Philip 0 siblings, 1 reply; 7+ messages in thread From: Joshua Crofts @ 2026-07-29 13:31 UTC (permalink / raw) To: Breno Leitao; +Cc: Andreas Hindborg, linux-kernel, syzbot+35790eb7861f8fc57382 On Wed, 29 Jul 2026 03:06:09 -0700 Breno Leitao <leitao@debian.org> wrote: > On Wed, Jul 29, 2026 at 08:55:05AM +0000, Joshua Crofts wrote: > > syzbot reported a "refcount_t: addition on 0; use-after-free" warning > > in configfs_get_config_item(). > > > > This occurs when configfs_get_config_item() races with a concurrent > > teardown (e.g. rmdir). When the target config_item's refcount drops to > > 0, configfs_get_config_item() calls config_item_get(), which > > unconditionally increments the refcount via kref_get(), triggering the > > refcount warning. > > Shouldn't be this the fix we are interested in fixing? > > > Fix this by using config_item_get_unless_zero(), which safely returns > > NULL if the refcount is already 0. > > This looks like more a workaround than a proper fix, no? > > I got the impression that we have a UAF behind this refcount issue, and > this is not being solved by this patch. Okay, so my interpretation was that this is a concurrency issue that's causing the UAF by incrementing a 0 refcount. Isn't this exactly the reason that config_item_get_unless_zero() was implemented? If the refcount is 0 then it just returns -ENOENT. -- Kind regards, Joshua Crofts ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item() 2026-07-29 13:31 ` Joshua Crofts @ 2026-07-29 15:05 ` Jeffin Philip 0 siblings, 0 replies; 7+ messages in thread From: Jeffin Philip @ 2026-07-29 15:05 UTC (permalink / raw) To: joshua.crofts1 Cc: a.hindborg, leitao, linux-kernel, syzbot+35790eb7861f8fc57382, Jeffin Philip On Wed, 29 Jul 2026 15:50:00 +0200 Joshua Crofts <joshua.crofts1@gmail.com> wrote: >On Wed, 29 Jul 2026 15:21:25 +0530 >Jeffin Philip <jeffinphilip14@gmail.com> wrote: > >> On Wed, 29 Jul 2026 09:00 +0000 >> Joshua Crofts <joshua.crofts1@gmail.com> wrote: >> >> >On Wed, 29 Jul 2026 08:55:05 +0000 >> >Joshua Crofts <joshua.crofts1@gmail.com> wrote: >> > >> >> syzbot reported a "refcount_t: addition on 0; use-after-free" warning >> >> in configfs_get_config_item(). >> >> >> >> This occurs when configfs_get_config_item() races with a concurrent >> >> teardown (e.g. rmdir). When the target config_item's refcount drops to >> >> 0, configfs_get_config_item() calls config_item_get(), which >> >> unconditionally increments the refcount via kref_get(), triggering the >> >> refcount warning. >> >> >> >> Fix this by using config_item_get_unless_zero(), which safely returns >> >> NULL if the refcount is already 0. >> >> Reported-by: syzbot+35790eb7861f8fc57382@syzkaller.appspotmail.com >> >> Closes: https://syzkaller.appspot.com/bug?extid=35790eb7861f8fc57382 >> >> Signed-off-by: Joshua Crofts <joshua.crofts1@gmail.com> >> >> --- >> >> fs/configfs/configfs_internal.h | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/fs/configfs/configfs_internal.h b/fs/configfs/configfs_internal.h >> >> index acdeea8e2..5448af3a8 100644 >> >> --- a/fs/configfs/configfs_internal.h >> >> +++ b/fs/configfs/configfs_internal.h >> >> @@ -124,7 +124,7 @@ static inline struct config_item *configfs_get_config_item(struct dentry *dentry >> >> spin_lock(&dentry->d_lock); >> >> if (!d_unhashed(dentry)) { >> >> struct configfs_dirent * sd = dentry->d_fsdata; >> >> - item = config_item_get(sd->s_element); >> >> + item = config_item_get_unless_zero(sd->s_element); >> >> } >> >> spin_unlock(&dentry->d_lock); >> >> I tested this solution first on syzbot and well, it errored out. But on testing it on a local >> build, it seems to trigger a different warning in configfs_get() regarding atomic count. Could you please >> look into it? > >Yeah, I've no idea why syzbot keeps failing on "FATAL: Kernel too old", >especially when testing against upstream. As for the different warning, >that's odd, because when I booted the kernel with the patch in QEMU and >ran the reproducer nothing happened. Could you please send the warning >in it's entirety? I assume you did not set panic_on_warn to 1. Try setting it first and re-run the reproducer. I would also encourage you to copy the .config file from syzbot and build the kernel yourself to test apart from using the prebuilt bzImage. Also as Breno said, this is more of a workaround, you could attempt to drop the dentry immediately after unlinking the group and then attempt to hold an extra reference(?) to the path and then safely free it later. Anyway, here is the warning and call trace: [ 44.009410][ T9943] ------------[ cut here ]------------ [ 44.009414][ T9943] !atomic_read(&sd->s_count) [ 44.009417][ T9943] WARNING: fs/configfs/configfs_internal.h:147 at configfs_symlink+0xe1c/0x1030, CPU#1: refcount/9943 [ 44.009429][ T9943] Modules linked in: [ 44.009437][ T9943] CPU: 1 UID: 0 PID: 9943 Comm: refcount Tainted: G B W 7.2.0-rc4-00365-g48a5a7ab8d6a-dirty #16 PREEMPT_{RT,(full)} [ 44.009445][ T9943] Tainted: [B]=BAD_PAGE, [W]=WARN [ 44.009447][ T9943] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-10.fc44 06/10/2025 [ 44.009450][ T9943] RIP: 0010:configfs_symlink+0xe1c/0x1030 [ 44.009455][ T9943] Code: ba bb 5b ff e9 0b f6 ff ff e8 b0 bb 5b ff 48 c7 c7 e0 54 18 8e e8 24 0f bf 08 e9 f0 f5 ff ff e8 0a c9 bc 08 e8 95 bb 5b ff 90 <0f> 0b 90 e9 8d f8 ff ff e8 87 bb 5b ff 90 0f 0b 90 e9 f [ 44.009460][ T9943] RSP: 0018:ffffc90021e1fc80 EFLAGS: 00010293 [ 44.009465][ T9943] RAX: ffffffff82683b0b RBX: 0000000000000000 RCX: ffff888028f11f40 [ 44.009469][ T9943] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 44.009473][ T9943] RBP: ffffc90021e1fd88 R08: 0000000000000000 R09: 0000000000000000 [ 44.009476][ T9943] R10: dffffc0000000000 R11: ffffed1004074d31 R12: dffffc0000000000 [ 44.009480][ T9943] R13: ffff8880203a6980 R14: ffffffff8bff9748 R15: 1ffff920043c3fa0 [ 44.009484][ T9943] FS: 00007fbc46816780(0000) GS:ffff8881db474000(0000) knlGS:0000000000000000 [ 44.009488][ T9943] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.009492][ T9943] CR2: 0000200000000000 CR3: 000000010e746000 CR4: 0000000000752ef0 [ 44.009498][ T9943] PKRU: 55555554 [ 44.009500][ T9943] Call Trace: [ 44.009502][ T9943] <TASK> [ 44.009506][ T9943] ? __pfx_configfs_symlink+0x10/0x10 [ 44.009511][ T9943] ? bpf_lsm_inode_symlink+0x9/0x20 [ 44.009518][ T9943] vfs_symlink+0x18b/0x330 [ 44.009523][ T9943] ? security_path_symlink+0xfd/0x360 [ 44.009529][ T9943] filename_symlinkat+0x1cd/0x420 [ 44.009534][ T9943] ? __might_fault+0xcb/0x130 [ 44.009540][ T9943] ? __pfx_filename_symlinkat+0x10/0x10 [ 44.009544][ T9943] ? do_getname+0x151/0x250 [ 44.009549][ T9943] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 44.009555][ T9943] __se_sys_symlinkat+0x4e/0x2b0 [ 44.009559][ T9943] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 44.009562][ T9944] Mass Storage Function, version: 2009/09/11 [ 44.009564][ T9943] do_syscall_64+0x174/0x580 [ 44.009569][ T9944] LUN: removable file: (no medium) [ 44.009572][ T9943] ? trace_irq_disable+0x3b/0x140 [ 44.009579][ T9943] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 44.009583][ T9943] RIP: 0033:0x7fbc46917fa9 [ 44.009588][ T9943] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f 1e 0d 00 f7 d8 8 [ 44.009592][ T9943] RSP: 002b:00007ffcb1d8ec68 EFLAGS: 00000287 ORIG_RAX: 000000000000010a [ 44.009598][ T9943] RAX: ffffffffffffffda RBX: 00007ffcb1d8edc8 RCX: 00007fbc46917fa9 [ 44.009601][ T9943] RDX: 0000200000000300 RSI: 00000000ffffff9c RDI: 0000200000000200 [ 44.009605][ T9943] RBP: 00007ffcb1d8ec70 R08: 00007ffcb1d8eca0 R09: 00007ffcb1d8eca0 [ 44.009616][ T9943] R10: 00007ffcb1d8eca0 R11: 0000000000000287 R12: 0000000000000000 [ 44.009620][ T9943] R13: 00007ffcb1d8edd8 R14: 00007fbc46a38000 R15: 0000000000402e00 [ 44.009625][ T9943] </TASK> [ 44.009628][ T9943] Kernel panic - not syncing: kernel: panic_on_warn set ... [ 44.009632][ T9943] CPU: 1 UID: 0 PID: 9943 Comm: refcount Tainted: G B W 7.2.0-rc4-00365-g48a5a7ab8d6a-dirty #16 PREEMPT_{RT,(full)} [ 44.009640][ T9943] Tainted: [B]=BAD_PAGE, [W]=WARN [ 44.009642][ T9943] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-10.fc44 06/10/2025 [ 44.009644][ T9943] Call Trace: [ 44.009646][ T9943] <TASK> [ 44.009648][ T9943] vpanic+0x56c/0xa60 [ 44.009653][ T9943] ? __pfx__printk+0x10/0x10 [ 44.009659][ T9943] ? __pfx_vpanic+0x10/0x10 [ 44.009663][ T9943] ? is_bpf_text_address+0x292/0x2b0 [ 44.009670][ T9943] ? is_bpf_text_address+0x26/0x2b0 [ 44.009678][ T9943] panic+0xc5/0xd0 [ 44.009682][ T9943] ? __pfx_panic+0x10/0x10 [ 44.009688][ T9943] __warn+0x315/0x4c0 [ 44.009692][ T9943] ? configfs_symlink+0xe1c/0x1030 [ 44.009698][ T9943] ? configfs_symlink+0xe1c/0x1030 [ 44.009703][ T9943] __report_bug+0x276/0x570 [ 44.009709][ T9943] ? configfs_symlink+0xe1c/0x1030 [ 44.009715][ T9943] ? __pfx___report_bug+0x10/0x10 [ 44.009722][ T9943] ? configfs_symlink+0xe1c/0x1030 [ 44.009727][ T9943] report_bug+0x16a/0x220 [ 44.009734][ T9943] ? configfs_symlink+0xe1c/0x1030 [ 44.009739][ T9943] ? configfs_symlink+0xe1e/0x1030 [ 44.009743][ T9943] handle_bug+0x9c/0x200 [ 44.009748][ T9943] exc_invalid_op+0x1a/0x50 [ 44.009753][ T9943] asm_exc_invalid_op+0x1a/0x20 [ 44.009757][ T9943] RIP: 0010:configfs_symlink+0xe1c/0x1030 [ 44.009763][ T9943] Code: ba bb 5b ff e9 0b f6 ff ff e8 b0 bb 5b ff 48 c7 c7 e0 54 18 8e e8 24 0f bf 08 e9 f0 f5 ff ff e8 0a c9 bc 08 e8 95 bb 5b ff 90 <0f> 0b 90 e9 8d f8 ff ff e8 87 bb 5b ff 90 0f 0b 90 e9 f [ 44.009767][ T9943] RSP: 0018:ffffc90021e1fc80 EFLAGS: 00010293 [ 44.009771][ T9943] RAX: ffffffff82683b0b RBX: 0000000000000000 RCX: ffff888028f11f40 [ 44.009775][ T9943] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 [ 44.009778][ T9943] RBP: ffffc90021e1fd88 R08: 0000000000000000 R09: 0000000000000000 [ 44.009781][ T9943] R10: dffffc0000000000 R11: ffffed1004074d31 R12: dffffc0000000000 [ 44.009785][ T9943] R13: ffff8880203a6980 R14: ffffffff8bff9748 R15: 1ffff920043c3fa0 [ 44.009790][ T9943] ? configfs_symlink+0xe1b/0x1030 [ 44.009796][ T9943] ? __pfx_configfs_symlink+0x10/0x10 [ 44.009801][ T9943] ? bpf_lsm_inode_symlink+0x9/0x20 [ 44.009807][ T9943] vfs_symlink+0x18b/0x330 [ 44.009811][ T9943] ? security_path_symlink+0xfd/0x360 [ 44.009817][ T9943] filename_symlinkat+0x1cd/0x420 [ 44.009821][ T9943] ? __might_fault+0xcb/0x130 [ 44.009827][ T9943] ? __pfx_filename_symlinkat+0x10/0x10 [ 44.009832][ T9943] ? do_getname+0x151/0x250 [ 44.009836][ T9943] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 44.009841][ T9943] __se_sys_symlinkat+0x4e/0x2b0 [ 44.009846][ T9943] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 44.009851][ T9943] do_syscall_64+0x174/0x580 [ 44.009857][ T9943] ? trace_irq_disable+0x3b/0x140 [ 44.009863][ T9943] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 44.009868][ T9943] RIP: 0033:0x7fbc46917fa9 [ 44.009871][ T9943] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1f 1e 0d 00 f7 d8 8 [ 44.009875][ T9943] RSP: 002b:00007ffcb1d8ec68 EFLAGS: 00000287 ORIG_RAX: 000000000000010a [ 44.009880][ T9943] RAX: ffffffffffffffda RBX: 00007ffcb1d8edc8 RCX: 00007fbc46917fa9 [ 44.009884][ T9943] RDX: 0000200000000300 RSI: 00000000ffffff9c RDI: 0000200000000200 [ 44.009888][ T9943] RBP: 00007ffcb1d8ec70 R08: 00007ffcb1d8eca0 R09: 00007ffcb1d8eca0 [ 44.009891][ T9943] R10: 00007ffcb1d8eca0 R11: 0000000000000287 R12: 0000000000000000 [ 44.009895][ T9943] R13: 00007ffcb1d8edd8 R14: 00007fbc46a38000 R15: 0000000000402e00 [ 44.009900][ T9943] </TASK> [ 44.010148][ T9943] Kernel Offset: disabled Let me know about your approach to fixing this. Thanks, Jeffin. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2026-07-29 15:06 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-07-29 8:55 [PATCH] configfs: fix refcount warning in configfs_get_config_item() Joshua Crofts 2026-07-29 9:00 ` Joshua Crofts 2026-07-29 9:51 ` Jeffin Philip 2026-07-29 13:50 ` Joshua Crofts 2026-07-29 10:06 ` Breno Leitao 2026-07-29 13:31 ` Joshua Crofts 2026-07-29 15:05 ` Jeffin Philip
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.