CVE-2023-54134

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> autofs: fix memory leak of waitqueues in autofs_catatonic_mode<br /> <br /> Syzkaller reports a memory leak:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff88810b279e00 (size 96):<br /> comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........&amp;#39;.....<br /> 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..&amp;#39;.............<br /> backtrace:<br /> [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046<br /> [] kmalloc include/linux/slab.h:576 [inline]<br /> [] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378<br /> [] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593<br /> [] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619<br /> [] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897<br /> [] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910<br /> [] vfs_ioctl fs/ioctl.c:51 [inline]<br /> [] __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> [] __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> autofs_wait_queue structs should be freed if their wait_ctr becomes zero.<br /> Otherwise they will be lost.<br /> <br /> In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new<br /> waitqueue struct is allocated in autofs_wait(), its initial wait_ctr<br /> equals 2. After that wait_event_killable() is interrupted (it returns<br /> -ERESTARTSYS), so that &amp;#39;wq-&gt;name.name == NULL&amp;#39; condition may be not<br /> satisfied. Actually, this condition can be satisfied when<br /> autofs_wait_release() or autofs_catatonic_mode() is called and, what is<br /> also important, wait_ctr is decremented in those places. Upon the exit of<br /> autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process<br /> begins: kill_sb calls autofs_catatonic_mode(), which should have freed the<br /> waitqueues, but it only decrements its usage counter to zero which is not<br /> a correct behaviour.<br /> <br /> edit:imk<br /> This description is of course not correct. The umount performed as a result<br /> of an expire is a umount of a mount that has been automounted, it&amp;#39;s not the<br /> autofs mount itself. They happen independently, usually after everything<br /> mounted within the autofs file system has been expired away. If everything<br /> hasn&amp;#39;t been expired away the automount daemon can still exit leaving mounts<br /> in place. But expires done in both cases will result in a notification that<br /> calls autofs_wait_release() with a result status. The problem case is the<br /> summary execution of of the automount daemon. In this case any waiting<br /> processes won&amp;#39;t be woken up until either they are terminated or the mount<br /> is umounted.<br /> end edit: imk<br /> <br /> So in catatonic mode we should free waitqueues which counter becomes zero.<br /> <br /> edit: imk<br /> Initially I was concerned that the calling of autofs_wait_release() and<br /> autofs_catatonic_mode() was not mutually exclusive but that can&amp;#39;t be the<br /> case (obviously) because the queue entry (or entries) is removed from the<br /> list when either of these two functions are called. Consequently the wait<br /> entry will be freed by only one of these functions or by the woken process<br /> in autofs_wait() depending on the order of the calls.<br /> end edit: imk