Re: [PATCH v2] media: dvb-usb-v2: set active_fe before the demux goes live

[Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>]

syzbot has filed a second report for the same race, this time through
the gl861 (Friio White) driver:

  https://syzkaller.appspot.com/bug?extid=ac020fbb657e00356ca2

  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000061
  KASAN: null-ptr-deref in range [0x0000000000000308-0x000000000000030f]
  RIP: 0010:friio_streaming_ctrl+0x43/0xd0 drivers/media/usb/dvb-usb-v2/gl861.c:521
   dvb_usb_start_feed+0x57a/0xc70 drivers/media/usb/dvb-usb-v2/dvb_usb_core.c:308
   dmx_section_feed_start_filtering+0x519/0x6b0
   dvb_dmxdev_filter_start+0xcdb/0x10d0
   dvb_demux_do_ioctl+0x470/0x540

The root cause is the same. The demux is registered while
adap->active_fe still holds the kzalloc'ed 0 and adap->fe[0] is NULL.
A DMX_SET_FILTER issued in that window passes the NULL frontend to
->streaming_ctrl(). In this report that is friio_streaming_ctrl(), which
dereferences fe->dvb (offset 0x308). The fault is in the core, not in
either driver, so this patch fixes both reports.

I tested this with syzbot's C reproducer, which binds a configfs
SourceSink gadget with the Friio VID/PID (0x7a69:0x0001) over dummy_hcd
while 8 threads keep opening the demux and starting section filters.
Both kernels were built from the same tree and syzbot's config, with and
without this patch:

  - without the patch: the oops above on the first Friio probe, 3/3 runs
  - with the patch:    no oops over 20 Friio probe cycles in 300s

Mauro, if you pick up v2, please add the following tags for the second
report:

Reported-by: syzbot+ac020fbb657e00356ca2@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ac020fbb657e00356ca2

Thanks,
Thang