In the Linux kernel, the following vulnerability has been resolved:
erofs: wake up all waiters after zerofslzma_head ready
When the user mounts the erofs second times, the decompression thread may hung. The problem happens due to a sequence of steps like the following:
1) Task A called zerofsloadlzmaconfig which obtain all of the node from the zerofslzma_head.
2) At this time, task B called the zerofslzmadecompress and wanted to get a node. But the zerofslzmahead was empty, the Task B had to sleep.
3) Task A release nodes and push nodes into the zerofslzma_head. But task B was still sleeping.
One example report when the hung happens: task:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000 Workqueue: erofsunzipd zerofsdecompressqueuework Call Trace: <TASK> _schedule+0x281/0x760 schedule+0x49/0xb0 zerofslzmadecompress+0x4bc/0x580 ? cpucoreflags+0x10/0x10 zerofsdecompresspcluster+0x49b/0xba0 ? _updateloadavgse+0x2b0/0x330 ? _updateloadavgse+0x2b0/0x330 ? updateloadavg+0x5f/0x690 ? updateloadavg+0x5f/0x690 ? setnextentity+0xbd/0x110 ? _rawspinunlock+0xd/0x20 zerofsdecompressqueue.isra.0+0x2e/0x50 zerofsdecompressqueuework+0x30/0x60 processonework+0x1d3/0x3a0 workerthread+0x45/0x3a0 ? processonework+0x3a0/0x3a0 kthread+0xe2/0x110 ? kthreadcompleteandexit+0x20/0x20 retfrom_fork+0x22/0x30 </TASK>