linux-kernel - Re: [RFC PATCH] thunderbolt: do not double dequeue a request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3x4clfg5ypbu2aoaewibncrq43o6f6xjyxgm2k2wv7dfosevb4@4sj7tbz7gfs5>
Date: Thu, 27 Mar 2025 20:26:51 +0900
From: Sergey Senozhatsky <senozhatsky@...omium.org>
To: Mika Westerberg <mika.westerberg@...ux.intel.com>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>, 
	Andreas Noever <andreas.noever@...il.com>, Michael Jamet <michael.jamet@...el.com>, 
	Mika Westerberg <westeri@...nel.org>, Yehezkel Bernat <YehezkelShB@...il.com>, 
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] thunderbolt: do not double dequeue a request

On (25/03/27 13:17), Mika Westerberg wrote:
> On Thu, Mar 27, 2025 at 02:52:54PM +0900, Sergey Senozhatsky wrote:
> > Some of our devices crash in tb_cfg_request_dequeue():
> > 
> >  general protection fault, probably for non-canonical address 0xdead000000000122: 0000 [#1] PREEMPT SMP NOPTI
> > 
> >  CPU: 6 PID: 91007 Comm: kworker/6:2 Tainted: G U W 6.6.65-06391-gbdec63d10750 #1 (HASH:cf42 1)
> >  RIP: 0010:tb_cfg_request_dequeue+0x2d/0xa0
> >  Call Trace:
> >  <TASK>
> >  ? tb_cfg_request_dequeue+0x2d/0xa0
> >  tb_cfg_request_work+0x33/0x80
> >  worker_thread+0x386/0x8f0
> >  kthread+0xed/0x110
> >  ret_from_fork+0x38/0x50
> >  ret_from_fork_asm+0x1b/0x30
> > 
> > The circumstances are unclear, however, the theory is that
> > tb_cfg_request_work() can be scheduled twice for a request:
> > first time via frame.callback from ring_work() and second
> > time from tb_cfg_request().  Both times kworkers will execute
> > tb_cfg_request_dequeue(), which results in double list_del()
> > from the ctl->request_queue (the list poison deference hints
> > at it: 0xdead000000000122).
> 
> I remember seeing similar but it was long time ago.

Another possibility probably can be tb_cfg_request_sync()

tb_cfg_request_sync()
	tb_cfg_request()
		schedule_work(&req->work) -> tb_cfg_request_dequeue()
	tb_cfg_request_cancel()
		schedule_work(&req->work) -> tb_cfg_request_dequeue()

[..]
> >  	mutex_lock(&ctl->request_queue_lock);
> > -	list_del(&req->list);
> > +	if (!test_bit(TB_CFG_REQUEST_ACTIVE, &req->flags)) {
> > +		mutex_unlock(&ctl->request_queue_lock);
> > +		return;
> > +	}
> > +
> > +	list_del_init(&req->list);
> 
> Why this change? We are not putting the req back to the list anymore.

Purely just to be safe.  Do you want me to resend without that
line?