In the Linux kernel, the following vulnerability has been resolved:

ext4: fix null-ptr-deref in ext4writeinfo

I caught a null-ptr-deref bug as follows:

KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4writeinfo+0x53/0x1b0 [...] Call Trace: dquotwritebackdquots+0x341/0x9a0 ext4syncfs+0x19e/0x800 __syncfilesystem+0x83/0x100 syncfilesystem+0x89/0xf0 genericshutdownsuper+0x79/0x3e0 killblocksuper+0xa1/0x110 deactivatelockedsuper+0xac/0x130 deactivatesuper+0xb6/0xd0 cleanupmnt+0x289/0x400 _cleanupmnt+0x16/0x20 taskworkrun+0x11c/0x1c0 exittousermodeprepare+0x203/0x210 syscallexittousermode+0x5b/0x3a0 dosyscall64+0x59/0x70 entrySYSCALL64afterhwframe+0x44/0xa9 ==================================================================

Above issue may happen as follows:

exittousermodeprepare taskworkrun __cleanupmnt cleanupmnt deactivate_super deactivatelockedsuper killblocksuper genericshutdownsuper shrinkdcacheforumount dentry = sb->sroot sb->sroot = NULL <--- Here set NULL syncfilesystem _syncfilesystem sb->sop->syncfs > ext4syncfs dquotwritebackdquots sb->dqop->writeinfo > ext4writeinfo ext4journalstart(dinode(sb->sroot), EXT4HTQUOTA, 2) dinode(sb->sroot) sroot->dinode <--- Null pointer dereference

To solve this problem, we use ext4journalstartsb directly to avoid sroot being used.