Message-ID: <CA3D308A-ED29-440C-A6C5-C5450CDA2C84@illinois.edu>
Date: Mon, 29 Apr 2024 15:42:36 +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,

Here is my QEMU booting command:

```
qemu-system-x86_64 \
	-m 2G \
	-smp 2 \
	-kernel linux/arch/x86/boot/bzImage \
	-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
	-drive file=image/bullseye-qemu.img,format=raw \
	-net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
	-net nic,model=e1000 \
	-enable-kvm \
	-nographic \
	-pidfile vm.pi
```

Plus, here is the config of vivid from my linux kernel building config:

```
CONFIG_VIDEO_VIVID=y
CONFIG_VIDEO_VIVID_CEC=y
CONFIG_VIDEO_VIVID_MAX_DEVS=64

CONFIG_CMDLINE="... vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 ..."

# Here is the full
CONFIG_CMDLINE="earlyprintk=serial net.ifnames=0 sysctl.kernel.hung_task_all_cpu_backtrace=1 ima_policy=tcb nf-conntrack-ftp.ports=20000 nf-conntrack-tftp.ports=20000 nf-conntrack-sip.ports=20000 nf-conntrack-irc.ports=20000 nf-conntrack-sane.ports=20000 binder.debug_mask=0 rcupdate.rcu_expedited=1 rcupdate.rcu_cpu_stall_cputime=1 no_hash_pointers page_owner=on sysctl.vm.nr_hugepages=4 sysctl.vm.nr_overcommit_hugepages=4 secretmem.enable=1 sysctl.max_rcu_stall_to_panic=1 msr.allow_writes=off coredump_filter=0xffff root=/dev/sda console=ttyS0 vsyscall=native numa=fake=2 kvm-intel.nested=1 spec_store_bypass_disable=prctl nopcid vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2 netrom.nr_ndevs=16 rose.rose_ndevs=16 smp.csd_lock_timeout=100000 watchdog_thresh=55 workqueue.watchdog_thresh=140 sysctl.net.core.netdev_unregister_timeout_secs=140 dummy_hcd.num=8 kmsan.panic=1"
```

Plus, I attached the current patch (git diff > patch).

Let me know if you need any further information.

Best,
Chenyuan

On 4/22/24, 1:57 PM, "Hans Verkuil" <hverkuil-cisco@...all.nl <mailto:hverkuil-cisco@...all.nl>> wrote:

On 22/04/2024 20:54, Yang, Chenyuan wrote:
> 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


Hmm, I don't see this. With how many CPU cores is the qemu instance configured?
And with what module options is the vivid module loaded?


Regards,


Hans


> ...
> ```
> 
> Best,
> Chenyuan
> 
> On 4/22/24, 10:04 AM, "Hans Verkuil" <hverkuil-cisco@...all.nl <mailto:hverkuil-cisco@...all.nl> <mailto: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> <mailto: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> <mailto:cy54@...inois.edu <mailto:cy54@...inois.edu>>>, linux-media@...r.kernel.org <mailto:linux-media@...r.kernel.org> <mailto:linux-media@...r.kernel.org <mailto:linux-media@...r.kernel.org>> <linux-media@...r.kernel.org <mailto:linux-media@...r.kernel.org> <mailto:linux-media@...r.kernel.org <mailto:linux-media@...r.kernel.org>>>, linux-kernel@...r.kernel.org <mailto:linux-kernel@...r.kernel.org> <mailto:linux-kernel@...r.kernel.org <mailto:linux-kernel@...r.kernel.org>> <linux-kernel@...r.kernel.org <mailto:linux-kernel@...r.kernel.org> <mailto:linux-kernel@...r.kernel.org <mailto:linux-kernel@...r.kernel.org>>>
>> Cc: jani.nikula@...el.com <mailto:jani.nikula@...el.com> <mailto:jani.nikula@...el.com <mailto:jani.nikula@...el.com>> <jani.nikula@...el.com <mailto:jani.nikula@...el.com> <mailto:jani.nikula@...el.com <mailto:jani.nikula@...el.com>>>, syzkaller@...glegroups.com <mailto:syzkaller@...glegroups.com> <mailto:syzkaller@...glegroups.com <mailto:syzkaller@...glegroups.com>> <syzkaller@...glegroups.com <mailto:syzkaller@...glegroups.com> <mailto:syzkaller@...glegroups.com <mailto:syzkaller@...glegroups.com>>>, mchehab@...nel.org <mailto:mchehab@...nel.org> <mailto:mchehab@...nel.org <mailto:mchehab@...nel.org>> <mchehab@...nel.org <mailto:mchehab@...nel.org> <mailto:mchehab@...nel.org <mailto:mchehab@...nel.org>>>, Zhao, Zijie <zijie4@...inois.edu <mailto:zijie4@...inois.edu> <mailto:zijie4@...inois.edu <mailto:zijie4@...inois.edu>>>, Zhang, Lingming <lingming@...inois.edu <mailto:lingming@...inois.edu> <mailto: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 "diff.patch" of type "application/octet-stream" (2684 bytes)

Download attachment "vivid-config" of type "application/octet-stream" (244982 bytes)

Powered by blists - more mailing lists