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@xxxxxxxxx <mailto:hverkuil-cisco@xxxxxxxxx>> 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@xxxxxxxxx <mailto:hverkuil-cisco@xxxxxxxxx> <mailto:hverkuil-cisco@xxxxxxxxx <mailto:hverkuil-cisco@xxxxxxxxx>>> 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@xxxxxxxxx <mailto:hverkuil-cisco@xxxxxxxxx> <mailto:hverkuil-cisco@xxxxxxxxx <mailto:hverkuil-cisco@xxxxxxxxx>>> >> Date: Friday, February 23, 2024 at 8:44 AM >> To: Yang, Chenyuan <cy54@xxxxxxxxxxxx <mailto:cy54@xxxxxxxxxxxx> <mailto:cy54@xxxxxxxxxxxx <mailto:cy54@xxxxxxxxxxxx>>>, linux-media@xxxxxxxxxxxxxxx <mailto:linux-media@xxxxxxxxxxxxxxx> <mailto:linux-media@xxxxxxxxxxxxxxx <mailto:linux-media@xxxxxxxxxxxxxxx>> <linux-media@xxxxxxxxxxxxxxx <mailto:linux-media@xxxxxxxxxxxxxxx> <mailto:linux-media@xxxxxxxxxxxxxxx <mailto:linux-media@xxxxxxxxxxxxxxx>>>, linux-kernel@xxxxxxxxxxxxxxx <mailto:linux-kernel@xxxxxxxxxxxxxxx> <mailto:linux-kernel@xxxxxxxxxxxxxxx <mailto:linux-kernel@xxxxxxxxxxxxxxx>> <linux-kernel@xxxxxxxxxxxxxxx <mailto:linux-kernel@xxxxxxxxxxxxxxx> <mailto:linux-kernel@xxxxxxxxxxxxxxx <mailto:linux-kernel@xxxxxxxxxxxxxxx>>> >> Cc: jani.nikula@xxxxxxxxx <mailto:jani.nikula@xxxxxxxxx> <mailto:jani.nikula@xxxxxxxxx <mailto:jani.nikula@xxxxxxxxx>> <jani.nikula@xxxxxxxxx <mailto:jani.nikula@xxxxxxxxx> <mailto:jani.nikula@xxxxxxxxx <mailto:jani.nikula@xxxxxxxxx>>>, syzkaller@xxxxxxxxxxxxxxxx <mailto:syzkaller@xxxxxxxxxxxxxxxx> <mailto:syzkaller@xxxxxxxxxxxxxxxx <mailto:syzkaller@xxxxxxxxxxxxxxxx>> <syzkaller@xxxxxxxxxxxxxxxx <mailto:syzkaller@xxxxxxxxxxxxxxxx> <mailto:syzkaller@xxxxxxxxxxxxxxxx <mailto:syzkaller@xxxxxxxxxxxxxxxx>>>, mchehab@xxxxxxxxxx <mailto:mchehab@xxxxxxxxxx> <mailto:mchehab@xxxxxxxxxx <mailto:mchehab@xxxxxxxxxx>> <mchehab@xxxxxxxxxx <mailto:mchehab@xxxxxxxxxx> <mailto:mchehab@xxxxxxxxxx <mailto:mchehab@xxxxxxxxxx>>>, Zhao, Zijie <zijie4@xxxxxxxxxxxx <mailto:zijie4@xxxxxxxxxxxx> <mailto:zijie4@xxxxxxxxxxxx <mailto:zijie4@xxxxxxxxxxxx>>>, Zhang, Lingming <lingming@xxxxxxxxxxxx <mailto:lingming@xxxxxxxxxxxx> <mailto:lingming@xxxxxxxxxxxx <mailto:lingming@xxxxxxxxxxxx>>> >> 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; >> > > > > >
Attachment:
diff.patch
Description: diff.patch
Attachment:
vivid-config
Description: vivid-config
