1. Patchew
  2. linux
  3. View series

[PATCH] crypto: ccp - Fix crash when rebind ccp device for ccp.ko

Mengbiao Xiong posted 1 patch 3 months, 2 weeks ago
There is a newer version of this series
drivers/crypto/ccp/ccp-debugfs.c | 1 +
1 file changed, 1 insertion(+)
[PATCH] crypto: ccp - Fix crash when rebind ccp device for ccp.ko
Posted by Mengbiao Xiong 3 months, 2 weeks ago 
When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding
the ccp device causes the following crash:

$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind
$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind

[  204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098
[  204.978026] #PF: supervisor write access in kernel mode
[  204.979126] #PF: error_code(0x0002) - not-present page
[  204.980226] PGD 0 P4D 0
[  204.981317] Oops: Oops: 0002 [#1] SMP NOPTI
...
[  204.997852] Call Trace:
[  204.999074]  <TASK>
[  205.000297]  start_creating+0x9f/0x1c0
[  205.001533]  debugfs_create_dir+0x1f/0x170
[  205.002769]  ? srso_return_thunk+0x5/0x5f
[  205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp]
[  205.005241]  ccp5_init+0x8b2/0x960 [ccp]
[  205.006469]  ccp_dev_init+0xd4/0x150 [ccp]
[  205.007709]  sp_init+0x5f/0x80 [ccp]
[  205.008942]  sp_pci_probe+0x283/0x2e0 [ccp]
[  205.010165]  ? srso_return_thunk+0x5/0x5f
[  205.011376]  local_pci_probe+0x4f/0xb0
[  205.012584]  pci_device_probe+0xdb/0x230
[  205.013810]  really_probe+0xed/0x380
[  205.015024]  __driver_probe_device+0x7e/0x160
[  205.016240]  device_driver_attach+0x2f/0x60
[  205.017457]  bind_store+0x7c/0xb0
[  205.018663]  drv_attr_store+0x28/0x40
[  205.019868]  sysfs_kf_write+0x5f/0x70
[  205.021065]  kernfs_fop_write_iter+0x145/0x1d0
[  205.022267]  vfs_write+0x308/0x440
[  205.023453]  ksys_write+0x6d/0xe0
[  205.024616]  __x64_sys_write+0x1e/0x30
[  205.025778]  x64_sys_call+0x16ba/0x2150
[  205.026942]  do_syscall_64+0x56/0x1e0
[  205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  205.029276] RIP: 0033:0x7fbc36f10104
[  205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5

This patch sets ccp_debugfs_dir to NULL after destroying it in
ccp5_debugfs_destroy, allowing the directory dentry to be
recreated when rebinding the ccp device.

Tested on AMD Ryzen 7 1700X.

Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information")
Signed-off-by: Mengbiao Xiong <xisme1998@gmail.com>
---
 drivers/crypto/ccp/ccp-debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/ccp/ccp-debugfs.c b/drivers/crypto/ccp/ccp-debugfs.c
index a1055554b..0d432f3c4 100644
--- a/drivers/crypto/ccp/ccp-debugfs.c
+++ b/drivers/crypto/ccp/ccp-debugfs.c
@@ -320,4 +320,5 @@ void ccp5_debugfs_setup(struct ccp_device *ccp)
 void ccp5_debugfs_destroy(void)
 {
 	debugfs_remove_recursive(ccp_debugfs_dir);
+	ccp_debugfs_dir = NULL;
 }
-- 
2.17.1
Re: [PATCH] crypto: ccp - Fix crash when rebind ccp device for ccp.ko
Posted by Tom Lendacky 3 months, 2 weeks ago 
On 6/23/25 01:25, Mengbiao Xiong wrote:
> When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding
> the ccp device causes the following crash:
> 
> $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind
> $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind
> 
> [  204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098
> [  204.978026] #PF: supervisor write access in kernel mode
> [  204.979126] #PF: error_code(0x0002) - not-present page
> [  204.980226] PGD 0 P4D 0
> [  204.981317] Oops: Oops: 0002 [#1] SMP NOPTI
> ...
> [  204.997852] Call Trace:
> [  204.999074]  <TASK>
> [  205.000297]  start_creating+0x9f/0x1c0
> [  205.001533]  debugfs_create_dir+0x1f/0x170
> [  205.002769]  ? srso_return_thunk+0x5/0x5f
> [  205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp]
> [  205.005241]  ccp5_init+0x8b2/0x960 [ccp]
> [  205.006469]  ccp_dev_init+0xd4/0x150 [ccp]
> [  205.007709]  sp_init+0x5f/0x80 [ccp]
> [  205.008942]  sp_pci_probe+0x283/0x2e0 [ccp]
> [  205.010165]  ? srso_return_thunk+0x5/0x5f
> [  205.011376]  local_pci_probe+0x4f/0xb0
> [  205.012584]  pci_device_probe+0xdb/0x230
> [  205.013810]  really_probe+0xed/0x380
> [  205.015024]  __driver_probe_device+0x7e/0x160
> [  205.016240]  device_driver_attach+0x2f/0x60
> [  205.017457]  bind_store+0x7c/0xb0
> [  205.018663]  drv_attr_store+0x28/0x40
> [  205.019868]  sysfs_kf_write+0x5f/0x70
> [  205.021065]  kernfs_fop_write_iter+0x145/0x1d0
> [  205.022267]  vfs_write+0x308/0x440
> [  205.023453]  ksys_write+0x6d/0xe0
> [  205.024616]  __x64_sys_write+0x1e/0x30
> [  205.025778]  x64_sys_call+0x16ba/0x2150
> [  205.026942]  do_syscall_64+0x56/0x1e0
> [  205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [  205.029276] RIP: 0033:0x7fbc36f10104
> [  205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
> 
> This patch sets ccp_debugfs_dir to NULL after destroying it in
> ccp5_debugfs_destroy, allowing the directory dentry to be
> recreated when rebinding the ccp device.
> 
> Tested on AMD Ryzen 7 1700X.
> 
> Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information")
> Signed-off-by: Mengbiao Xiong <xisme1998@gmail.com>
> ---
>  drivers/crypto/ccp/ccp-debugfs.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/crypto/ccp/ccp-debugfs.c b/drivers/crypto/ccp/ccp-debugfs.c
> index a1055554b..0d432f3c4 100644
> --- a/drivers/crypto/ccp/ccp-debugfs.c
> +++ b/drivers/crypto/ccp/ccp-debugfs.c
> @@ -320,4 +320,5 @@ void ccp5_debugfs_setup(struct ccp_device *ccp)
>  void ccp5_debugfs_destroy(void)
>  {
>  	debugfs_remove_recursive(ccp_debugfs_dir);
> +	ccp_debugfs_dir = NULL;

Hmmm... it seems like this should be protected by the mutex similar to how
ccp5_debugfs_setup() is, right?

Maybe something like:

	mutex_lock(&ccp_debugfs_lock);
	if (ccp_debugfs_dir) {
		debugfs_remove_recursive(ccp_debugfs_dir);
		ccp_debugfs_dir = NULL;
	}
	mutex_unlock(&ccp_debugfs_lock);

That should also fix the issue, thoughts?

Thanks,
Tom

>  }
Re: [PATCH] crypto: ccp - Fix crash when rebind ccp device for ccp.ko
Posted by 1998 Xisme 3 months, 2 weeks ago 
You're right. But I checked with checkpatch.pl and it reported:

WARNING: debugfs_remove_recursive(NULL) is safe and this check is
probably not required
#70: FILE: drivers/crypto/ccp/ccp-debugfs.c:324:
+       if (ccp_debugfs_dir) {
+               debugfs_remove_recursive(ccp_debugfs_dir);

Perhaps we could simplify it to:

        mutex_lock(&ccp_debugfs_lock);
        debugfs_remove_recursive(ccp_debugfs_dir);
        ccp_debugfs_dir = NULL;
        mutex_unlock(&ccp_debugfs_lock);

I'll send a v2 patch soon.

Tom Lendacky <thomas.lendacky@amd.com> 于2025年6月24日周二 01:17写道：
>
> On 6/23/25 01:25, Mengbiao Xiong wrote:
> > When CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding
> > the ccp device causes the following crash:
> >
> > $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind
> > $ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind
> >
> > [  204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098
> > [  204.978026] #PF: supervisor write access in kernel mode
> > [  204.979126] #PF: error_code(0x0002) - not-present page
> > [  204.980226] PGD 0 P4D 0
> > [  204.981317] Oops: Oops: 0002 [#1] SMP NOPTI
> > ...
> > [  204.997852] Call Trace:
> > [  204.999074]  <TASK>
> > [  205.000297]  start_creating+0x9f/0x1c0
> > [  205.001533]  debugfs_create_dir+0x1f/0x170
> > [  205.002769]  ? srso_return_thunk+0x5/0x5f
> > [  205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp]
> > [  205.005241]  ccp5_init+0x8b2/0x960 [ccp]
> > [  205.006469]  ccp_dev_init+0xd4/0x150 [ccp]
> > [  205.007709]  sp_init+0x5f/0x80 [ccp]
> > [  205.008942]  sp_pci_probe+0x283/0x2e0 [ccp]
> > [  205.010165]  ? srso_return_thunk+0x5/0x5f
> > [  205.011376]  local_pci_probe+0x4f/0xb0
> > [  205.012584]  pci_device_probe+0xdb/0x230
> > [  205.013810]  really_probe+0xed/0x380
> > [  205.015024]  __driver_probe_device+0x7e/0x160
> > [  205.016240]  device_driver_attach+0x2f/0x60
> > [  205.017457]  bind_store+0x7c/0xb0
> > [  205.018663]  drv_attr_store+0x28/0x40
> > [  205.019868]  sysfs_kf_write+0x5f/0x70
> > [  205.021065]  kernfs_fop_write_iter+0x145/0x1d0
> > [  205.022267]  vfs_write+0x308/0x440
> > [  205.023453]  ksys_write+0x6d/0xe0
> > [  205.024616]  __x64_sys_write+0x1e/0x30
> > [  205.025778]  x64_sys_call+0x16ba/0x2150
> > [  205.026942]  do_syscall_64+0x56/0x1e0
> > [  205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > [  205.029276] RIP: 0033:0x7fbc36f10104
> > [  205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5
> >
> > This patch sets ccp_debugfs_dir to NULL after destroying it in
> > ccp5_debugfs_destroy, allowing the directory dentry to be
> > recreated when rebinding the ccp device.
> >
> > Tested on AMD Ryzen 7 1700X.
> >
> > Fixes: 3cdbe346ed3f ("crypto: ccp - Add debugfs entries for CCP information")
> > Signed-off-by: Mengbiao Xiong <xisme1998@gmail.com>
> > ---
> >  drivers/crypto/ccp/ccp-debugfs.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/crypto/ccp/ccp-debugfs.c b/drivers/crypto/ccp/ccp-debugfs.c
> > index a1055554b..0d432f3c4 100644
> > --- a/drivers/crypto/ccp/ccp-debugfs.c
> > +++ b/drivers/crypto/ccp/ccp-debugfs.c
> > @@ -320,4 +320,5 @@ void ccp5_debugfs_setup(struct ccp_device *ccp)
> >  void ccp5_debugfs_destroy(void)
> >  {
> >       debugfs_remove_recursive(ccp_debugfs_dir);
> > +     ccp_debugfs_dir = NULL;
>
> Hmmm... it seems like this should be protected by the mutex similar to how
> ccp5_debugfs_setup() is, right?
>
> Maybe something like:
>
>         mutex_lock(&ccp_debugfs_lock);
>         if (ccp_debugfs_dir) {
>                 debugfs_remove_recursive(ccp_debugfs_dir);
>                 ccp_debugfs_dir = NULL;
>         }
>         mutex_unlock(&ccp_debugfs_lock);
>
> That should also fix the issue, thoughts?
>
> Thanks,
> Tom
>
> >  }

Patchew 2.1-devel-b67e4c2

© 2016 - 2025 Red Hat, Inc.