linux-kernel - Re: [Linux Kernel Bugs] KASAN: slab-use-after-free Read in cec_queue_msg_fh and 4 other crashes in the cec device (`cec

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] [thread-next>] [day] [month] [year] [list]
Message-ID: <C84ADEF3-5553-41AF-B127-85D5630CC8A1@illinois.edu>
Date: Mon, 22 Apr 2024 18:54:12 +0000
From: "Yang, Chenyuan" <cy54@...inois.edu>
To: Hans Verkuil <hverkuil-cisco@...all.nl>,
        "linux-media@...r.kernel.org"
	<linux-media@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: "jani.nikula@...el.com" <jani.nikula@...el.com>,
        "syzkaller@...glegroups.com" <syzkaller@...glegroups.com>,
        "mchehab@...nel.org" <mchehab@...nel.org>,
        "Zhao, Zijie"
	<zijie4@...inois.edu>,
        "Zhang, Lingming" <lingming@...inois.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 Hans,

Such timeout logs happen all the time when I execute the C program attached.

```
gcc -pthread repro.c -o exe
./exe
```

The logs are from QEMU:

```
Debian GNU/Linux 11 syzkaller ttyS0

syzkaller login: [  326.705401][   T51] Bluetooth: hci0: sending frame failed (-49)
[  326.707063][ T4466] Bluetooth: hci0: Opcode 0x1003 failed: -49
[  335.945400][ T4466] Bluetooth: hci0: Opcode 0x1003 failed: -110
[  335.945417][   T51] Bluetooth: hci0: command 0x1003 tx timeout
[  390.885042][ T2019] cec-vivid-000-vid-out0: transmit timed out
[  390.894890][ T2050] cec-vivid-002-vid-cap0: transmit timed out
[  390.895540][ T2034] cec-vivid-001-vid-cap0: transmit timed out
[  390.905041][ T2067] cec-vivid-003-vid-out0: transmit timed out
[  392.985033][ T2018] cec-vivid-000-vid-cap0: transmit timed out
...
```

Best,
Chenyuan

On 4/22/24, 10:04 AM, "Hans Verkuil" <hverkuil-cisco@...all.nl <mailto:hverkuil-cisco@...all.nl>> wrote:


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@...all.nl <mailto:hverkuil-cisco@...all.nl>>
> Date: Friday, February 23, 2024 at 8:44 AM
> To: Yang, Chenyuan <cy54@...inois.edu <mailto:cy54@...inois.edu>>, linux-media@...r.kernel.org <mailto:linux-media@...r.kernel.org> <linux-media@...r.kernel.org <mailto:linux-media@...r.kernel.org>>, linux-kernel@...r.kernel.org <mailto:linux-kernel@...r.kernel.org> <linux-kernel@...r.kernel.org <mailto:linux-kernel@...r.kernel.org>>
> Cc: jani.nikula@...el.com <mailto:jani.nikula@...el.com> <jani.nikula@...el.com <mailto:jani.nikula@...el.com>>, syzkaller@...glegroups.com <mailto:syzkaller@...glegroups.com> <syzkaller@...glegroups.com <mailto:syzkaller@...glegroups.com>>, mchehab@...nel.org <mailto:mchehab@...nel.org> <mchehab@...nel.org <mailto:mchehab@...nel.org>>, Zhao, Zijie <zijie4@...inois.edu <mailto:zijie4@...inois.edu>>, Zhang, Lingming <lingming@...inois.edu <mailto:lingming@...inois.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;
> 






Download attachment "repro.c" of type "application/octet-stream" (8130 bytes)