CVE-2024-26972: ubifs: ubifs_symlink: Fix memleak of inode->i_link in error path

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->ilink before marking inode bad. Method 2 is picked, it has less influence, personally, I think.