Critical Vulnerability Information Issue Description: - When fails (because it is full), must submit an I/O request via , allocate a new I/O request using an empty , and then retry the call. - However, at this point, has already been called, which increments ; the retry will again invoke , but there will never be a matching call. This causes the folio to remain permanently locked, and all waiters will be stuck in . Trigger Conditions: - This bug was introduced by commit ce63cb62d794, but was originally unreachable in practice because had space for 256 folios. It became easily triggerable only after commit 9f74ae8c9ac9 reduced the array capacity to 16 folios. - The bug can be triggered from userspace by manually invoking readahead, for example: Fix: - should only be called after succeeds. This is safe: the asynchronous completion call to will not unlock the folio, because still holds a reference until the final release. Related Commits: - Fixes: ce63cb62d794 ("erofs: support unencoded inodes for fileio") - Fixes: 9f74ae8c9ac9 ("erofs: shorten bvecs[] for file-backed mounts") Sign-offs and Reviews: - Signed-off-by: Max Kellermann - Reviewed-by: Gao Xiang - Tested-by: Hongbo Li - Signed-off-by: Greg Kroah-Hartman