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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tencent_211B474BC21B1D25ABBA31BB5133AC9E0608@qq.com>
Date: Thu, 22 Feb 2024 18:58:54 +0800
From: Edward Adam Davis <eadavis@...com>
To: hverkuil-cisco@...all.nl
Cc: eadavis@...com,
	linux-kernel@...r.kernel.org,
	linux-media@...r.kernel.org,
	mchehab@...nel.org,
	syzbot+116b65a23bc791ae49a6@...kaller.appspotmail.com,
	syzkaller-bugs@...glegroups.com
Subject: Re: [PATCH] media/cec/core: fix task hung in cec_claim_log_addrs

On Wed, 21 Feb 2024 15:38:47 +0100, Hans Verkuil wrote:
> > After unlocking adap->lock in cec_claim_log_addrs(), cec_claim_log_addrs() may
> > re-enter, causing this issue to occur.
> 
> But if it is called again, then it should hit this at the start of the function:
> 
>         if (WARN_ON(adap->is_configuring || adap->is_configured))
>                 return;
> 
> I'm still not sure what causes the KASAN hung task since I cannot seem to reproduce
> it, and because it is hard for me to find enough time to dig into this.

Please pay attention to the following section of code in cec_config_thread_func():
   3 unconfigure:
   2         for (i = 0; i < las->num_log_addrs; i++)
   1                 las->log_addr[i] = CEC_LOG_ADDR_INVALID;
1573         cec_adap_unconfigure(adap);           // [1], is_configured = false;
   1         adap->is_configuring = false;	   // [2], is_configuring = false;
   2         adap->must_reconfigure = false;
   3         adap->kthread_config = NULL;
   4         complete(&adap->config_completion);
   5         mutex_unlock(&adap->lock);		   // [3], Afterwards

And the following code is included in cec_claim_log-addrs():
   3         } else if (block) {
   2                 mutex_unlock(&adap->lock);
   1                 wait_for_completion(&adap->config_completion);
1607                 mutex_lock(&adap->lock);      // [4], During the period before re obtaining the adap->lock, how did cec_claim_log-addrs() re-enter?

BR,
edward


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ