In the Linux kernel, the following vulnerability has been resolved: smb: client: let smbddestroy() call disableworksync(&info->postsendcreditswork) In smbddestroy() we may destroy the memory so we better wait until postsendcreditswork is no longer pending and will never be started again. I actually just hit the case using rxe: WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxeverbs.c:1032 rxepostrecv+0x1ee/0x480 [rdmarxe] ... [ 5305.686979] [ T138] smbdpostrecv+0x445/0xc10 [cifs] [ 5305.687135] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687149] [ T138] ? kasancheckwrite+0x14/0x30 [ 5305.687185] [ T138] ? _pfxsmbdpostrecv+0x10/0x10 [cifs] [ 5305.687329] [ T138] ? _pfxrawspinlockirqsave+0x10/0x10 [ 5305.687356] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687368] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687378] [ T138] ? _rawspinunlockirqrestore+0x11/0x60 [ 5305.687389] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687399] [ T138] ? getreceivebuffer+0x168/0x210 [cifs] [ 5305.687555] [ T138] smbdpostsendcredits+0x382/0x4b0 [cifs] [ 5305.687701] [ T138] ? pfxsmbdpostsendcredits+0x10/0x10 [cifs] [ 5305.687855] [ T138] ? _pfxschedule+0x10/0x10 [ 5305.687865] [ T138] ? pfxrawspinlockirq+0x10/0x10 [ 5305.687875] [ T138] ? queuedelayedworkon+0x8e/0xa0 [ 5305.687889] [ T138] processonework+0x629/0xf80 [ 5305.687908] [ T138] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 5305.687917] [ T138] ? _kasancheckwrite+0x14/0x30 [ 5305.687933] [ T138] workerthread+0x87f/0x1570 ... It means rxepostrecv was called after rdmadestroyqp(). This happened because putreceivebuffer() was triggered by ibdrainqp() and called: queuework(info->workqueue, &info->postsendcredits_work);