linux-kernel - Re: [syzbot] [syzbot] [kernel?] inconsistent lock state in sock_hash_delete

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: <8734rpzffr.ffs@tglx>
Date: Sat, 13 Apr 2024 13:10:16 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: syzbot <syzbot+1dab15008502531a13d2@...kaller.appspotmail.com>,
 linux-kernel@...r.kernel.org
Cc: lizhi.xu@...driver.com, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [syzbot] [syzbot] [kernel?] inconsistent lock state in
 sock_hash_delete_elem

On Sun, Mar 31 2024 at 23:46, syzbot wrote:
> For archival purposes, forwarding an incoming command email to
> linux-kernel@...r.kernel.org.
>
> ***
>
> Subject: [syzbot] [kernel?] inconsistent lock state in sock_hash_delete_elem
> Author: lizhi.xu@...driver.com
>
> #syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git fe46a7dd189e
>
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index d44efa0d0611..07a3c1d2c2d8 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -5676,7 +5676,7 @@ void scheduler_tick(void)
>  
>  	sched_clock_tick();
>  
> -	rq_lock(rq, &rf);
> +	rq_lock_irqsave(rq, &rf);

That's just wrong. scheduler_tick() is invoked from hard interrupt
context with interrupts disabled.
  
>  	update_rq_clock(rq);
>  	thermal_pressure = arch_scale_thermal_pressure(cpu_of(rq));
> @@ -5688,7 +5688,7 @@ void scheduler_tick(void)
>  	sched_core_tick(rq);
>  	task_tick_mm_cid(rq, curr);
>  
> -	rq_unlock(rq, &rf);
> +	rq_unlock_irqrestore(rq, &rf);
>  
>  	if (sched_feat(LATENCY_WARN) && resched_latency)
>  		resched_latency_warn(cpu, resched_latency);