linux-kernel - Re: [PATCH] tty/hvc_console: fix console lock ordering with spinlock

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>] [day] [month] [year] [list]

Date:   Tue, 4 Apr 2017 15:54:01 +0300
From:   Denis Kirjanov <kda@...ux-powerpc.org>
To:     Michael Ellerman <mpe@...erman.id.au>
Cc:     gregkh@...uxfoundation.org, jslaby@...e.com,
        linuxppc-dev@...abs.org, linux-kernel@...r.kernel.org,
        "benh@...nel.crashing.org" <benh@...nel.crashing.org>
Subject: Re: [PATCH] tty/hvc_console: fix console lock ordering with spinlock

On 4/4/17, Michael Ellerman <mpe@...erman.id.au> wrote:
> Denis Kirjanov <kda@...ux-powerpc.org> writes:
>
>> hvc_remove() takes a spin lock first then acquires the console
>> semaphore. This situation can easily lead to a deadlock scenario
>> where we call scheduler with spin lock held.
>
> Have you actually hit the deadlock? Because that code's been like that
> for years and I've never received a bug report.

Nope, I didn't. I've found the bug in the code while looking at the
lockdep output

>
>> diff --git a/drivers/tty/hvc/hvc_console.c
>> b/drivers/tty/hvc/hvc_console.c
>> index b19ae36..a8d3991 100644
>> --- a/drivers/tty/hvc/hvc_console.c
>> +++ b/drivers/tty/hvc/hvc_console.c
>> @@ -920,17 +920,17 @@ int hvc_remove(struct hvc_struct *hp)
>>
>>  	tty = tty_port_tty_get(&hp->port);
>>
>> +	console_lock();
>>  	spin_lock_irqsave(&hp->lock, flags);
>>  	if (hp->index < MAX_NR_HVC_CONSOLES) {
>> -		console_lock();
>>  		vtermnos[hp->index] = -1;
>>  		cons_ops[hp->index] = NULL;
>> -		console_unlock();
>>  	}
>>
>>  	/* Don't whack hp->irq because tty_hangup() will need to free the irq.
>> */
>>
>>  	spin_unlock_irqrestore(&hp->lock, flags);
>> +	console_unlock();
>
> I get that you're trying to do the minimal change, but I don't think the
> result is ideal. If this isn't a console hvc then we take both locks but
> do nothing.
>
> So what about:
>
> 	if (hp->index < MAX_NR_HVC_CONSOLES) {
> 		console_lock();
> 		spin_lock_irqsave(&hp->lock, flags);
> 		vtermnos[hp->index] = -1;
> 		cons_ops[hp->index] = NULL;
> 		spin_unlock_irqrestore(&hp->lock, flags);
> 		console_unlock();
> 	}
Are you sure that we don't corrupt the hp->index between hvc_poll in
interrupt context and hvc_remoev?

>
> cheers
>