In the Linux kernel, the following vulnerability has been resolved:
ubifs: ubifssymlink: Fix memleak of inode->ilink in error path
For error handling path in ubifssymlink(), inode will be marked as bad first, then iput() is invoked. If inode->ilink is initialized by fscryptencryptsymlink() in encryption scenario, inode->ilink won't be freed by callchain ubifsfreeinode -> fscryptfreeinode in error handling path, because makebadinode() has changed 'inode->imode' as 'SIFREG'. Following kmemleak is easy to be reproduced by injecting error in ubifsjnlupdate() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8): comm "ln", pid 1692, jiffies 4294914701 (age 12.045s) backtrace: kmemdup+0x32/0x70 _fscryptencryptsymlink+0xed/0x1c0 ubifssymlink+0x210/0x300 [ubifs] vfssymlink+0x216/0x360 dosymlinkat+0x11a/0x190 dosyscall64+0x3b/0xe0 There are two ways fixing it: 1. Remove makebadinode() in error handling path. We can do that because ubifsevictinode() will do same processes for good symlink inode and bad symlink inode, for inode->inlink checking is before isbadinode(). 2. Free inode->i_link before marking inode bad. Method 2 is picked, it has less influence, personally, I think.