linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
To: "Yang, Chenyuan" <cy54@illinois.edu>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Cc: "jani.nikula@intel.com" <jani.nikula@intel.com>,
	"syzkaller@googlegroups.com" <syzkaller@googlegroups.com>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"Zhao, Zijie" <zijie4@illinois.edu>,
	"Zhang, Lingming" <lingming@illinois.edu>
Subject: Re: [Linux Kernel Bugs] KASAN: slab-use-after-free Read in cec_queue_msg_fh and 4 other crashes in the cec device (`cec_ioctl`)
Date: Mon, 22 Apr 2024 17:04:43 +0200	[thread overview]
Message-ID: <f196c736-dbfe-4ca0-995b-1720bf530edf@xs4all.nl> (raw)
In-Reply-To: <7E36CBBD-F2AD-4D98-8D4E-F52E62C3E812@illinois.edu>

Hi Chenyuan,

My apologies for the delay, I missed your email.

On 26/02/2024 13:27, Yang, Chenyuan wrote:
> Hi Hans,
> 
> Thank you for your continued efforts in investigating this bug and implementing the new patch!
> 
> Regarding the two warnings, they have been addressed by this new patch and are no longer reproducible. Additionally, I conducted a 48-hour fuzzing test on the CEC driver, which has successfully eliminated the previous hanging issue.
> 
> One thing to note that the system will now log timeout events:
> ```
> [ 2281.265385][ T2034] cec-vivid-001-vid-out0: transmit timed out
> [ 2282.994510][ T2017] cec-vivid-000-vid-cap0: transmit timed out
> [ 2283.063484][ T2050] cec-vivid-002-vid-out0: transmit timed out
> [ 2283.073468][ T2065] cec-vivid-003-vid-cap0: transmit timed out
> [ 2283.373518][ T2033] cec-vivid-001-vid-cap0: transmit timed out
> [ 2285.113544][ T2018] cec-vivid-000-vid-out0: transmit timed out
> [ 2285.193502][ T2050] cec-vivid-002-vid-out0: transmit timed out
> [ 2285.193570][ T2065] cec-vivid-003-vid-cap0: transmit timed out
> [ 2285.513570][ T2033] cec-vivid-001-vid-cap0: transmit timed out
> ```

Is this happening all the time, or just once in a (long?) while?

Regards,

	Hans

> 
> Best,
> Chenyuan
> 
> From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> Date: Friday, February 23, 2024 at 8:44 AM
> To: Yang, Chenyuan <cy54@illinois.edu>, linux-media@vger.kernel.org <linux-media@vger.kernel.org>, linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>
> Cc: jani.nikula@intel.com <jani.nikula@intel.com>, syzkaller@googlegroups.com <syzkaller@googlegroups.com>, mchehab@kernel.org <mchehab@kernel.org>, Zhao, Zijie <zijie4@illinois.edu>, Zhang, Lingming <lingming@illinois.edu>
> Subject: Re: [Linux Kernel Bugs] KASAN: slab-use-after-free Read in cec_queue_msg_fh and 4 other crashes in the cec device (`cec_ioctl`)
> Hi Chenyuan,
> 
> Here is another patch for you to try. I think it is good for blocking CEC_ADAP_S_LOG_ADDRS
> ioctl calls, but if the filehandle is in non-blocking mode, I'm still not certain it
> is correct. But one issue at a time :-)
> 
> Regards,
> 
>         Hans
> 
> diff --git a/drivers/media/cec/core/cec-adap.c b/drivers/media/cec/core/cec-adap.c
> index 559a172ebc6c..a493cbce2456 100644
> --- a/drivers/media/cec/core/cec-adap.c
> +++ b/drivers/media/cec/core/cec-adap.c
> @@ -936,8 +936,7 @@ int cec_transmit_msg_fh(struct cec_adapter *adap, struct cec_msg *msg,
>           */
>          mutex_unlock(&adap->lock);
>          wait_for_completion_killable(&data->c);
> -       if (!data->completed)
> -               cancel_delayed_work_sync(&data->work);
> +       cancel_delayed_work_sync(&data->work);
>          mutex_lock(&adap->lock);
> 
>          /* Cancel the transmit if it was interrupted */
> @@ -1575,9 +1574,12 @@ static int cec_config_thread_func(void *arg)
>   */
>  static void cec_claim_log_addrs(struct cec_adapter *adap, bool block)
>  {
> -       if (WARN_ON(adap->is_configuring || adap->is_configured))
> +       if (WARN_ON(adap->is_claiming_log_addrs ||
> +                   adap->is_configuring || adap->is_configured))
>                  return;
> 
> +       adap->is_claiming_log_addrs = true;
> +
>          init_completion(&adap->config_completion);
> 
>          /* Ready to kick off the thread */
> @@ -1592,6 +1594,7 @@ static void cec_claim_log_addrs(struct cec_adapter *adap, bool block)
>                  wait_for_completion(&adap->config_completion);
>                  mutex_lock(&adap->lock);
>          }
> +       adap->is_claiming_log_addrs = false;
>  }
> 
>  /*
> diff --git a/drivers/media/cec/core/cec-api.c b/drivers/media/cec/core/cec-api.c
> index 67dc79ef1705..3ef915344304 100644
> --- a/drivers/media/cec/core/cec-api.c
> +++ b/drivers/media/cec/core/cec-api.c
> @@ -178,7 +178,7 @@ static long cec_adap_s_log_addrs(struct cec_adapter *adap, struct cec_fh *fh,
>                             CEC_LOG_ADDRS_FL_ALLOW_RC_PASSTHRU |
>                             CEC_LOG_ADDRS_FL_CDC_ONLY;
>          mutex_lock(&adap->lock);
> -       if (!adap->is_configuring &&
> +       if (!adap->is_claiming_log_addrs && !adap->is_configuring &&
>              (!log_addrs.num_log_addrs || !adap->is_configured) &&
>              !cec_is_busy(adap, fh)) {
>                  err = __cec_s_log_addrs(adap, &log_addrs, block);
> @@ -664,6 +664,8 @@ static int cec_release(struct inode *inode, struct file *filp)
>                  list_del_init(&data->xfer_list);
>          }
>          mutex_unlock(&adap->lock);
> +
> +       mutex_lock(&fh->lock);
>          while (!list_empty(&fh->msgs)) {
>                  struct cec_msg_entry *entry =
>                          list_first_entry(&fh->msgs, struct cec_msg_entry, list);
> @@ -681,6 +683,7 @@ static int cec_release(struct inode *inode, struct file *filp)
>                          kfree(entry);
>                  }
>          }
> +       mutex_unlock(&fh->lock);
>          kfree(fh);
> 
>          cec_put_device(devnode);
> diff --git a/include/media/cec.h b/include/media/cec.h
> index 10c9cf6058b7..cc3fcd0496c3 100644
> --- a/include/media/cec.h
> +++ b/include/media/cec.h
> @@ -258,6 +258,7 @@ struct cec_adapter {
>          u16 phys_addr;
>          bool needs_hpd;
>          bool is_enabled;
> +       bool is_claiming_log_addrs;
>          bool is_configuring;
>          bool must_reconfigure;
>          bool is_configured;
> 


  parent reply	other threads:[~2024-04-22 15:04 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-28  2:33 [Linux Kernel Bugs] KASAN: slab-use-after-free Read in cec_queue_msg_fh and 4 other crashes in the cec device (`cec_ioctl`) Yang, Chenyuan
2023-12-29  6:23 ` Dmitry Vyukov
     [not found] ` <SN6PR11MB345527101A2C8A1AC99B04B5FA712@SN6PR11MB3455.namprd11.prod.outlook.com>
2024-01-18  7:52   ` Hans Verkuil
2024-01-19  8:17 ` Hans Verkuil
2024-01-22 19:11   ` Yang, Chenyuan
2024-01-23  8:02     ` Hans Verkuil
2024-01-23 10:39       ` Hans Verkuil
2024-01-24 13:33   ` Yang, Chenyuan
2024-01-25 10:35     ` Hans Verkuil
2024-01-29  3:03   ` Yang, Chenyuan
2024-01-30 14:35     ` Hans Verkuil
2024-02-12 14:42       ` Hans Verkuil
2024-02-13 15:40         ` Yang, Chenyuan
2024-02-13 16:05           ` Yang, Chenyuan
2024-02-23 14:44           ` Hans Verkuil
     [not found]             ` <PH7PR11MB5768B0BC3C042A6EA4EC1EF0A0542@PH7PR11MB5768.namprd11.prod.outlook.com>
2024-02-26 12:27               ` Yang, Chenyuan
2024-04-19 14:51                 ` Takashi Iwai
2024-04-22 12:14                   ` Hans Verkuil
2024-04-22 19:30                     ` Takashi Iwai
2024-04-22 15:04                 ` Hans Verkuil [this message]
2024-04-22 18:54                   ` Yang, Chenyuan
2024-04-22 20:57                     ` Hans Verkuil
2024-04-29 15:42                       ` Yang, Chenyuan
2024-04-30 10:26                         ` Hans Verkuil
2024-04-30 17:06                           ` Yang, Chenyuan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f196c736-dbfe-4ca0-995b-1720bf530edf@xs4all.nl \
    --to=hverkuil-cisco@xs4all.nl \
    --cc=cy54@illinois.edu \
    --cc=jani.nikula@intel.com \
    --cc=lingming@illinois.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=zijie4@illinois.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).