In the Linux kernel, the following vulnerability has been resolved: net/9p: fix double req put in p9fdcancelled Syzkaller reports a KASAN issue as below: general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f] CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:listdel include/linux/list.h:114 [inline] RIP: 0010:listdelentry include/linux/list.h:137 [inline] RIP: 0010:listdel include/linux/list.h:148 [inline] RIP: 0010:p9fdcancelled+0xe9/0x200 net/9p/transfd.c:734 Call Trace: <TASK> p9clientflush+0x351/0x440 net/9p/client.c:614 p9clientrpc+0xb6b/0xc70 net/9p/client.c:734 p9clientversion net/9p/client.c:920 [inline] p9clientcreate+0xb51/0x1240 net/9p/client.c:1027 v9fssessioninit+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fsmount+0xba/0xcb0 fs/9p/vfssuper.c:126 legacygettree+0x108/0x220 fs/fscontext.c:632 vfsgettree+0x8e/0x300 fs/super.c:1573 donewmount fs/namespace.c:3056 [inline] pathmount+0x6a6/0x1e90 fs/namespace.c:3386 domount fs/namespace.c:3399 [inline] _dosysmount fs/namespace.c:3607 [inline] _sesysmount fs/namespace.c:3584 [inline] _x64sysmount+0x283/0x300 fs/namespace.c:3584 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8 This happens because of a race condition between: - The 9p client sending an invalid flush request and later cleaning it up; - The 9p client in p9readwork() canceled all pending requests. Thread 1 Thread 2 ... p9clientcreate() ... p9fdcreate() ... p9conncreate() ... // start Thread 2 INITWORK(&m->rq, p9readwork); p9readwork() ... p9clientrpc() ... ... p9conncancel() ... spinlock(&m->reqlock); ... p9fdcancelled() ... ... spinunlock(&m->reqlock); // status rewrite p9clientcb(m->client, req, REQSTATUSERROR) // first remove listdel(&req->reqlist); ... spinlock(&m->reqlock) ... // second remove listdel(&req->reqlist); spinunlock(&m->reqlock) ... Commit 74d6a5d56629 ("9p/transfd: Fix concurrency del of reqlist in p9fdcancelled/p9readwork") fixes a concurrency issue in the 9p filesystem client where the reqlist could be deleted simultaneously by both p9readwork and p9fdcancelled functions, but for the case where req->status equals REQSTATUSRCVD. Update the check for req->status in p9fd_cancelled to skip processing not just received requests, but anything that is not SENT, as whatever changed the state from SENT also removed the request from its list. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. [updated the check from status == RECV || status == ERROR to status != SENT]