CVE-2022-50770

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

ocfs2: fix memory leak in ocfs2mountvolume()

There is a memory leak reported by kmemleak:

unreferenced object 0xffff88810cc65e60 (size 32): comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s) hex dump (first 32 bytes): 10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 ................ 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff8170f73d>] __kmalloc+0x4d/0x150 [<ffffffffa0ac3f51>] ocfs2computereplayslots+0x121/0x330 [ocfs2] [<ffffffffa0b65165>] ocfs2checkvolume+0x485/0x900 [ocfs2] [<ffffffffa0b68129>] ocfs2mountvolume.isra.0+0x1e9/0x650 [ocfs2] [<ffffffffa0b7160b>] ocfs2fillsuper+0xe0b/0x1740 [ocfs2] [<ffffffff818e1fe2>] mountbdev+0x312/0x400 [<ffffffff819a086d>] legacygettree+0xed/0x1d0 [<ffffffff818de82d>] vfsgettree+0x7d/0x230 [<ffffffff81957f92>] pathmount+0xd62/0x1760 [<ffffffff81958a5a>] domount+0xca/0xe0 [<ffffffff81958d3c>] __x64sysmount+0x12c/0x1a0 [<ffffffff82f26f15>] dosyscall64+0x35/0x80 [<ffffffff8300006a>] entrySYSCALL64afterhwframe+0x46/0xb0

This call stack is related to two problems. Firstly, the ocfs2 super uses "replaymap" to trace online/offline slots, in order to recover offline slots during recovery and mount. But when ocfs2truncateloginit() returns an error in ocfs2mountvolume(), the memory of "replaymap" will not be freed in error handling path. Secondly, the memory of "replaymap" will not be freed if dmakeroot() returns an error in ocfs2fillsuper(). But the memory of "replaymap" will be freed normally when completing recovery and mount in ocfs2completemountrecovery().

Fix the first problem by adding error handling path to free "replaymap" when ocfs2truncateloginit() fails. And fix the second problem by calling ocfs2freereplayslots(osb) in the error handling path "outdismount". In addition, since ocfs2freereplay_slots() is static, it is necessary to remove its static attribute and declare it in header file.