All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: "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>,
	"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: Fri, 19 Apr 2024 16:51:25 +0200	[thread overview]
Message-ID: <87le59s8wi.wl-tiwai@suse.de> (raw)
In-Reply-To: <7E36CBBD-F2AD-4D98-8D4E-F52E62C3E812@illinois.edu>

On Mon, 26 Feb 2024 13:27:16 +0100,
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
> ```
> 
> Best,
> Chenyuan

Hi Hans,

how is the current status of this bug fix?  It seems that the thread
stalled, and I wonder how we can go further.

I'm asking it because CVE-2024-23848 was assigned and we've been asked
about the bug fix.


Thanks!

Takashi

> 
> 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;
> 

  reply	other threads:[~2024-04-19 14:51 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 [this message]
2024-04-22 12:14                   ` Hans Verkuil
2024-04-22 19:30                     ` Takashi Iwai
2024-04-22 15:04                 ` Hans Verkuil
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=87le59s8wi.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=cy54@illinois.edu \
    --cc=hverkuil-cisco@xs4all.nl \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.