In the Linux kernel, the following vulnerability has been resolved:
nullblk: fix null-ptr-dereference while configuring 'power' and 'submitqueues'
Writing 'power' and 'submit_queues' concurrently will trigger kernel panic:
Test script:
modprobe nullblk nrdevices=0 mkdir -p /sys/kernel/config/nullb/nullb0 while true; do echo 1 > submitqueues; echo 4 > submitqueues; done & while true; do echo 1 > power; echo 0 > power; done
Test result:
BUG: kernel NULL pointer dereference, address: 0000000000000148 Oops: 0000 [#1] PREEMPT SMP RIP: 0010:_lockacquire+0x41d/0x28f0 Call Trace: <TASK> lockacquire+0x121/0x450 downwrite+0x5f/0x1d0 simplerecursiveremoval+0x12f/0x5c0 blkmqdebugfsunregisterhctxs+0x7c/0x100 blkmqupdatenrhwqueues+0x4a3/0x720 nullbupdatenrhwqueues+0x71/0xf0 [nullblk] nullbdevicesubmitqueuesstore+0x79/0xf0 [nullblk] configfswriteiter+0x119/0x1e0 vfswrite+0x326/0x730 ksys_write+0x74/0x150
This is because delgendisk() can concurrent with blkmqupdatenrhwqueues():
nullbdevicepowerstore nullbapplysubmitqueues nulldeldev delgendisk nullbupdatenrhwqueues if (!dev->nullb) // still set while gendisk is deleted return 0 blkmqupdatenrhwqueues dev->nullb = NULL
Fix this problem by resuing the global mutex to protect nullbdevicepowerstore() and nullbupdatenrhw_queues() from configfs.