CVE-2022-50770

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

ocfs2: fix memory leak in ocfs2_mount_volume()

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:
[] __kmalloc+0x4d/0x150
[] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]
[] ocfs2_check_volume+0x485/0x900 [ocfs2]
[] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]
[] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]
[] mount_bdev+0x312/0x400
[] legacy_get_tree+0xed/0x1d0
[] vfs_get_tree+0x7d/0x230
[] path_mount+0xd62/0x1760
[] do_mount+0xca/0xe0
[] __x64_sys_mount+0x12c/0x1a0
[] do_syscall_64+0x35/0x80
[] entry_SYSCALL_64_after_hwframe+0x46/0xb0

This call stack is related to two problems. Firstly, the ocfs2 super uses
“replay_map” to trace online/offline slots, in order to recover offline
slots during recovery and mount. But when ocfs2_truncate_log_init()
returns an error in ocfs2_mount_volume(), the memory of “replay_map” will
not be freed in error handling path. Secondly, the memory of “replay_map”
will not be freed if d_make_root() returns an error in ocfs2_fill_super().
But the memory of “replay_map” will be freed normally when completing
recovery and mount in ocfs2_complete_mount_recovery().

Fix the first problem by adding error handling path to free “replay_map”
when ocfs2_truncate_log_init() fails. And fix the second problem by
calling ocfs2_free_replay_slots(osb) in the error handling path
“out_dismount”. In addition, since ocfs2_free_replay_slots() is static,
it is necessary to remove its static attribute and declare it in header
file.