Bug 208751

Summary: KASAN: Use-after-free bug in xlog_alloc_log
Product: File System Reporter: Zu-Ming Jiang (jjzuming)
Component: XFSAssignee: FileSystem/XFS Default Virtual Assignee (filesystem_xfs)
Status: RESOLVED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: dsterba, sandeen
Priority: P1    
Hardware: x86-64   
OS: Linux   
Kernel Version: Linux 5.4 Subsystem:
Regression: No Bisected commit-id:
Attachments: KASAN Report

Description Zu-Ming Jiang 2020-07-31 12:09:48 UTC
Created attachment 290699 [details]
KASAN Report

KASAN report a use-after-free bug when the alloc_workqueue() return NULL in the following call stack:

   1. alloc_workqueue(xfs_log.c, 1480)
   2. xlog_alloc_log(xfs_log.c, 599)
   3. xfs_log_mount(xfs_mount.c, 811)
   4. xfs_mountfs(xfs_super.c, 1732)
   5. xfs_fs_fill_super
   6. mount_bdev(xfs_super.c, 1806)
   7. xfs_fs_mount

Possible reason:
When alloc_workqueue() returns NULL, the kernel thread enter the error handling code entrance out_free_iclog. In out_free_iclog, the thread frees log->l_iclog in a for loop. However, log->l_iclog is a ring. When all iclogs have been freed, The for loop will come to the ring head and free the iclogs again.

Result:
The Linux kernel crashes.
Comment 1 Eric Sandeen 2020-07-31 19:20:51 UTC
You've reported this on a 5.4.0 kernel from November 2019 (please, in future bug reports include the kernel version more prominently)

This commit:

commit 798a9cada4694ca8d970259f216cec47e675bfd5
Author: Brian Foster <bfoster@redhat.com>
Date:   Tue Dec 3 07:53:15 2019 -0800

    xfs: fix mount failure crash on invalid iclog memory access
    
    syzbot (via KASAN) reports a use-after-free in the error path of
    xlog_alloc_log(). Specifically, the iclog freeing loop doesn't
    handle the case of a fully initialized ->l_iclog linked list.
    Instead, it assumes that the list is partially constructed and NULL
    terminated.
    
    This bug manifested because there was no possible error scenario
    after iclog list setup when the original code was added.  Subsequent
    code and associated error conditions were added some time later,
    while the original error handling code was never updated. Fix up the
    error loop to terminate either on a NULL iclog or reaching the end
    of the list.
    
    Reported-by: syzbot+c732f8644185de340492@syzkaller.appspotmail.com
    Signed-off-by: Brian Foster <bfoster@redhat.com>
    Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
    Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>


went into v5.5

I believe this is already resolved; if you have a reproducer can you please test?  If you believe this bug is still not fixed, please re-open this bug.