[PATCH] configfs: fix refcount warning in configfs_get_config_item()

[PATCH] configfs: fix refcount warning in configfs_get_config_item()

[Joshua Crofts]

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

Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item()

[Joshua Crofts]

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

Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item()

[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.

Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item()

[Breno Leitao]

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.

Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item()

[Joshua Crofts]

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

Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item()

[Joshua Crofts]

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

Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item()

[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.