On Fri, 09 Jun 2023 10:22:38 +0200, Mauro Carvalho Chehab wrote: > > As reported by Thomas Voegtle <tv@xxxxxxxx>, sometimes a DVB card does > not initialize properly booting Linux 6.4-rc4. This is not always, maybe > in 3 out of 4 attempts. > > After double-checking, the root cause seems to be related to the > UAF fix, which is causing a race issue: > > [ 26.332149] tda10071 7-0005: found a 'NXP TDA10071' in cold state, will try to load a firmware > [ 26.340779] tda10071 7-0005: downloading firmware from file 'dvb-fe-tda10071.fw' > [ 989.277402] INFO: task vdr:743 blocked for more than 491 seconds. > [ 989.283504] Not tainted 6.4.0-rc5-i5 #249 > [ 989.288036] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > [ 989.295860] task:vdr state:D stack:0 pid:743 ppid:711 flags:0x00004002 > [ 989.295865] Call Trace: > [ 989.295867] <TASK> > [ 989.295869] __schedule+0x2ea/0x12d0 > [ 989.295877] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 > [ 989.295881] schedule+0x57/0xc0 > [ 989.295884] schedule_preempt_disabled+0xc/0x20 > [ 989.295887] __mutex_lock.isra.16+0x237/0x480 > [ 989.295891] ? dvb_get_property.isra.10+0x1bc/0xa50 > [ 989.295898] ? dvb_frontend_stop+0x36/0x180 > [ 989.338777] dvb_frontend_stop+0x36/0x180 > [ 989.338781] dvb_frontend_open+0x2f1/0x470 > [ 989.338784] dvb_device_open+0x81/0xf0 > [ 989.338804] ? exact_lock+0x20/0x20 > [ 989.338808] chrdev_open+0x7f/0x1c0 > [ 989.338811] ? generic_permission+0x1a2/0x230 > [ 989.338813] ? link_path_walk.part.63+0x340/0x380 > [ 989.338815] ? exact_lock+0x20/0x20 > [ 989.338817] do_dentry_open+0x18e/0x450 > [ 989.374030] path_openat+0xca5/0xe00 > [ 989.374031] ? terminate_walk+0xec/0x100 > [ 989.374034] ? path_lookupat+0x93/0x140 > [ 989.374036] do_filp_open+0xc0/0x140 > [ 989.374038] ? __call_rcu_common.constprop.91+0x92/0x240 > [ 989.374041] ? __check_object_size+0x147/0x260 > [ 989.374043] ? __check_object_size+0x147/0x260 > [ 989.374045] ? alloc_fd+0xbb/0x180 > [ 989.374048] ? do_sys_openat2+0x243/0x310 > [ 989.374050] do_sys_openat2+0x243/0x310 > [ 989.374052] do_sys_open+0x52/0x80 > [ 989.374055] do_syscall_64+0x5b/0x80 > [ 989.421335] ? __task_pid_nr_ns+0x92/0xa0 > [ 989.421337] ? syscall_exit_to_user_mode+0x20/0x40 > [ 989.421339] ? do_syscall_64+0x67/0x80 > [ 989.421341] ? syscall_exit_to_user_mode+0x20/0x40 > [ 989.421343] ? do_syscall_64+0x67/0x80 > [ 989.421345] entry_SYSCALL_64_after_hwframe+0x63/0xcd > [ 989.421348] RIP: 0033:0x7fe895d067e3 > [ 989.421349] RSP: 002b:00007fff933c2ba0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 > [ 989.421351] RAX: ffffffffffffffda RBX: 00007fff933c2c10 RCX: 00007fe895d067e3 > [ 989.421352] RDX: 0000000000000802 RSI: 00005594acdce160 RDI: 00000000ffffff9c > [ 989.421353] RBP: 0000000000000802 R08: 0000000000000000 R09: 0000000000000000 > [ 989.421353] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000001 > [ 989.421354] R13: 00007fff933c2ca0 R14: 00000000ffffffff R15: 00007fff933c2c90 > [ 989.421355] </TASK> > > This reverts commit 6769a0b7ee0c3b31e1b22c3fadff2bfb642de23f. > > Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> Note that CVE-2022-45885 was assigned for the original issue as a security bug, and now it's reopened by this revert. Please let me know if you have a fix in another form. thanks, Takashi
