linux-toradex.git/drivers/media/usb/dvb-usb, branch master Linux kernel for Apalis and Colibri modules media: rc: fix race between unregister and urb/irq callbacks 2026-03-17T13:43:56+00:00 Sean Young sean@mess.org 2025-12-20T10:33:26+00:00 dccc0c3ddf8f16071736f98a7d6dd46a2d43e037 Some rc device drivers have a race condition between rc_unregister_device() and irq or urb callbacks. This is because rc_unregister_device() does two things, it marks the device as unregistered so no new commands can be issued and then it calls rc_free_device(). This means the driver has no chance to cancel any pending urb callbacks or interrupts after the device has been marked as unregistered. Those callbacks may access struct rc_dev or its members (e.g. struct ir_raw_event_ctrl), which have been freed by rc_free_device(). This change removes the implicit call to rc_free_device() from rc_unregister_device(). This means that device drivers can call rc_unregister_device() in their remove or disconnect function, then cancel all the urbs and interrupts before explicitly calling rc_free_device(). Note this is an alternative fix for an issue found by Haotian Zhang, see the Closes: tags. Reported-by: Haotian Zhang <vulab@iscas.ac.cn> Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/ Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/ Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
Some rc device drivers have a race condition between rc_unregister_device()
and irq or urb callbacks. This is because rc_unregister_device() does two
things, it marks the device as unregistered so no new commands can be
issued and then it calls rc_free_device(). This means the driver has no
chance to cancel any pending urb callbacks or interrupts after the device
has been marked as unregistered. Those callbacks may access struct rc_dev
or its members (e.g. struct ir_raw_event_ctrl), which have been freed by
rc_free_device().

This change removes the implicit call to rc_free_device() from
rc_unregister_device(). This means that device drivers can call
rc_unregister_device() in their remove or disconnect function, then cancel
all the urbs and interrupts before explicitly calling rc_free_device().

Note this is an alternative fix for an issue found by Haotian Zhang, see
the Closes: tags.

Reported-by: Haotian Zhang <vulab@iscas.ac.cn>
Closes: https://lore.kernel.org/linux-media/20251114101432.2566-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101418.2548-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114101346.2530-1-vulab@iscas.ac.cn/
Closes: https://lore.kernel.org/linux-media/20251114090605.2413-1-vulab@iscas.ac.cn/
Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Convert more 'alloc_obj' cases to default GFP_KERNEL arguments 2026-02-22T04:03:00+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-22T04:03:00+00:00 32a92f8c89326985e05dce8b22d3f0aa07a3e1bd This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
This converts some of the visually simpler cases that have been split
over multiple lines.  I only did the ones that are easy to verify the
resulting diff by having just that final GFP_KERNEL argument on the next
line.

Somebody should probably do a proper coccinelle script for this, but for
me the trivial script actually resulted in an assertion failure in the
middle of the script.  I probably had made it a bit _too_ trivial.

So after fighting that far a while I decided to just do some of the
syntactically simpler cases with variations of the previous 'sed'
scripts.

The more syntactically complex multi-line cases would mostly really want
whitespace cleanup anyway.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Convert 'alloc_obj' family to use the new default GFP_KERNEL argument 2026-02-22T01:09:51+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-02-22T00:37:42+00:00 bf4afc53b77aeaa48b5409da5c8da6bb4eff7f43 This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
This was done entirely with mindless brute force, using

    git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
        xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'

to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.

Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.

For the same reason the 'flex' versions will be done as a separate
conversion.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
treewide: Replace kmalloc with kmalloc_obj for non-scalar types 2026-02-21T09:02:28+00:00 Kees Cook kees@kernel.org 2026-02-21T07:49:23+00:00 69050f8d6d075dc01af7a5f2f550a8067510366f This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org> 
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:

Single allocations:	kmalloc(sizeof(TYPE), ...)
are replaced with:	kmalloc_obj(TYPE, ...)

Array allocations:	kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with:	kmalloc_objs(TYPE, COUNT, ...)

Flex array allocations:	kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with:	kmalloc_flex(*PTR, FAM, COUNT, ...)

(where TYPE may also be *VAR)

The resulting allocations no longer return "void *", instead returning
"TYPE *".

Signed-off-by: Kees Cook <kees@kernel.org>
media: dvb-usb: pctv452e: move snd/rcv len check before kmalloc 2025-11-04T12:31:02+00:00 Edward Adam Davis eadavis@qq.com 2025-11-03T11:57:49+00:00 1a31cb2782104969e48c7ce7e4fc06e403fcb5cf syzbot reported a uninit-value in pctv452e_i2c_msg. [1] When the snd_len or rcv_len check fails and jumps to failed, buf is uninitialized, triggering the uninit-value issue. Move the snd/rcv length check before kmalloc, and return -EINVAL directly if the condition is met. [1] BUG: KMSAN: uninit-value in hex_string+0x681/0x740 lib/vsprintf.c:1220 pctv452e_i2c_msg+0x82a/0x8f0 drivers/media/usb/dvb-usb/pctv452e.c:467 pctv452e_i2c_xfer+0x2e6/0x4c0 drivers/media/usb/dvb-usb/pctv452e.c:502 Reported-by: syzbot+480edd2cadb85ddb4bbe@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=480edd2cadb85ddb4bbe Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
syzbot reported a uninit-value in pctv452e_i2c_msg. [1]

When the snd_len or rcv_len check fails and jumps to failed, buf is
uninitialized, triggering the uninit-value issue.

Move the snd/rcv length check before kmalloc, and return -EINVAL directly
if the condition is met.

[1]
BUG: KMSAN: uninit-value in hex_string+0x681/0x740 lib/vsprintf.c:1220
 pctv452e_i2c_msg+0x82a/0x8f0 drivers/media/usb/dvb-usb/pctv452e.c:467
 pctv452e_i2c_xfer+0x2e6/0x4c0 drivers/media/usb/dvb-usb/pctv452e.c:502

Reported-by: syzbot+480edd2cadb85ddb4bbe@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=480edd2cadb85ddb4bbe
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg() 2025-10-14T13:07:36+00:00 Jeongjun Park aha310510@gmail.com 2025-04-21T12:52:44+00:00 b91e6aafe8d356086cc621bc03e35ba2299e4788 rlen value is a user-controlled value, but dtv5100_i2c_msg() does not check the size of the rlen value. Therefore, if it is set to a value larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data. Therefore, we need to add proper range checking to prevent this vuln. Fixes: 60688d5e6e6e ("V4L/DVB (8735): dtv5100: replace dummy frontend by zl10353") Cc: stable@vger.kernel.org Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org> 
rlen value is a user-controlled value, but dtv5100_i2c_msg() does not
check the size of the rlen value. Therefore, if it is set to a value
larger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.

Therefore, we need to add proper range checking to prevent this vuln.

Fixes: 60688d5e6e6e ("V4L/DVB (8735): dtv5100: replace dummy frontend by zl10353")
Cc: stable@vger.kernel.org
Signed-off-by: Jeongjun Park <aha310510@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
media: cxusb: no longer judge rbuf when the write fails 2025-04-25T13:14:31+00:00 Edward Adam Davis eadavis@qq.com 2025-04-05T11:56:41+00:00 73fb3b92da84637e3817580fa205d48065924e15 syzbot reported a uninit-value in cxusb_i2c_xfer. [1] Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw() succeeds and rlen is greater than 0, the read operation of usb_bulk_msg() will be executed to read rlen bytes of data from the dvb device into the rbuf. In this case, although rlen is 1, the write operation failed which resulted in the dvb read operation not being executed, and ultimately variable i was not initialized. [1] BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Reported-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=526bd95c0ec629993bf3 Tested-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com Fixes: 22c6d93a7310 ("[PATCH] dvb: usb: support Medion hybrid USB2.0 DVB-T/analogue box") Cc: stable@vger.kernel.org Signed-off-by: Edward Adam Davis <eadavis@qq.com> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> 
syzbot reported a uninit-value in cxusb_i2c_xfer. [1]

Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()
succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()
will be executed to read rlen bytes of data from the dvb device into the
rbuf.

In this case, although rlen is 1, the write operation failed which resulted
in the dvb read operation not being executed, and ultimately variable i was
not initialized.

[1]
BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]
 cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196
 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1
 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315
 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343
 i2c_master_send include/linux/i2c.h:109 [inline]
 i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183
 do_loop_readv_writev fs/read_write.c:848 [inline]
 vfs_writev+0x963/0x14e0 fs/read_write.c:1057
 do_writev+0x247/0x5c0 fs/read_write.c:1101
 __do_sys_writev fs/read_write.c:1169 [inline]
 __se_sys_writev fs/read_write.c:1166 [inline]
 __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166
 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Reported-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=526bd95c0ec629993bf3
Tested-by: syzbot+526bd95c0ec629993bf3@syzkaller.appspotmail.com
Fixes: 22c6d93a7310 ("[PATCH] dvb: usb: support Medion hybrid USB2.0 DVB-T/analogue box")
Cc: stable@vger.kernel.org
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
media: dvb-usb: Constify struct i2c_algorithm 2025-02-21T09:33:12+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2024-09-07T20:36:29+00:00 fc91d334e045dab1b5f01bd88b4906ad1dfbd223 'struct i2c_algorithm' are not modified in these drivers. Constifying this structure moves some data to a read-only section, so increase overall security, especially when the structure holds some function pointers. More over, dvb_usb_device_properties->i2c_algo seems to only be copied in i2c_adapter->algo, which is already a "const struct i2c_algorithm". This is done in dvb_usb_i2c_init() On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 30571 5916 36 36523 8eab drivers/media/usb/dvb-usb/af9005.o After: ===== text data bss dec hex filename 30667 5852 36 36555 8ecb drivers/media/usb/dvb-usb/af9005.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> 
'struct i2c_algorithm' are not modified in these drivers.

Constifying this structure moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.

More over, dvb_usb_device_properties->i2c_algo seems to only be copied in
i2c_adapter->algo, which is already a "const struct i2c_algorithm".
This is done in dvb_usb_i2c_init()

On a x86_64, with allmodconfig, as an example:
Before:
======
   text	   data	    bss	    dec	    hex	filename
  30571	   5916	     36	  36523	   8eab	drivers/media/usb/dvb-usb/af9005.o

After:
=====
   text	   data	    bss	    dec	    hex	filename
  30667	   5852	     36	  36555	   8ecb	drivers/media/usb/dvb-usb/af9005.o

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
media: dvb-usb: Constify struct usb_device_id 2025-02-21T09:33:08+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2025-01-05T21:19:57+00:00 51f76375e3d27177fa211ab653871e5644bcbecb 'struct usb_device_id' is not modified in these drivers. Constifying this structure moves some data to a read-only section, so increase overall security. In order to do that, struct dvb_usb_device_description (in dvb-usb.h) also needs to be updated. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 1983 4240 4 6227 1853 drivers/media/usb/dvb-usb/a800.o After: ===== text data bss dec hex filename 2079 4144 4 6227 1853 drivers/media/usb/dvb-usb/a800.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> 
'struct usb_device_id' is not modified in these drivers.

Constifying this structure moves some data to a read-only section, so
increase overall security.

In order to do that, struct dvb_usb_device_description (in dvb-usb.h) also
needs to be updated.

On a x86_64, with allmodconfig, as an example:
Before:
======
   text	   data	    bss	    dec	    hex	filename
   1983	   4240	      4	   6227	   1853	drivers/media/usb/dvb-usb/a800.o

After:
=====
   text	   data	    bss	    dec	    hex	filename
   2079	   4144	      4	   6227	   1853	drivers/media/usb/dvb-usb/a800.o

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
media: usb: use kmalloc_array() to replace kmalloc() 2025-02-21T09:33:04+00:00 Zhang Heng zhangheng@kylinos.cn 2025-01-14T01:12:55+00:00 8deb1e2a392bbebe159aa4f4d33f4e0a62260c24 Use kmalloc_array() to replace kmalloc() with multiplication. kmalloc_array() has multiply overflow check, which will be safer. Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> 
Use kmalloc_array() to replace kmalloc() with multiplication.
kmalloc_array() has multiply overflow check, which will be safer.

Signed-off-by: Zhang Heng <zhangheng@kylinos.cn>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>