CVE-2024-12986
Vie, 27/12/2024 – 16:15
CVE-2024-12986
CVE-2024-12986
Vie, 27/12/2024 – 16:15
CVE-2024-12986
CVE-2024-12856
Vie, 27/12/2024 – 16:15
CVE-2024-12856
CVE-2024-12987
Vie, 27/12/2024 – 16:15
CVE-2024-12987
CVE-2024-56509
Vie, 27/12/2024 – 16:15
CVE-2024-56509
CVE-2024-56508
Vie, 27/12/2024 – 16:15
CVE-2024-56508
CVE-2024-56507
Vie, 27/12/2024 – 16:15
CVE-2024-56507
CVE-2024-56579
Vie, 27/12/2024 – 15:15
CVE-2024-56579
media: amphion: Set video drvdata before register video device
The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops.
CVE-2024-56578
Vie, 27/12/2024 – 15:15
CVE-2024-56578
media: imx-jpeg: Set video drvdata before register video device
The video drvdata should be set before the video device is registered,
otherwise video_drvdata() may return NULL in the open() file ops, and led
to oops.
CVE-2024-56577
Vie, 27/12/2024 – 15:15
CVE-2024-56577
media: mtk-jpeg: Fix null-ptr-deref during unload module
The workqueue should be destroyed in mtk_jpeg_core.c since commit
09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise
the below calltrace can be easily triggered.
[ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023
[ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
…
[ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17
…
[ 677.882838] pc : destroy_workqueue+0x3c/0x770
[ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]
[ 677.884314] sp : ffff80008ad974f0
[ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070
[ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690
[ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000
[ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0
[ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10
[ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d
[ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90
[ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001
[ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000
[ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118
[ 677.893977] Call trace:
[ 677.894297] destroy_workqueue+0x3c/0x770
[ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]
[ 677.895677] devm_action_release+0x50/0x90
[ 677.896211] release_nodes+0xe8/0x170
[ 677.896688] devres_release_all+0xf8/0x178
[ 677.897219] device_unbind_cleanup+0x24/0x170
[ 677.897785] device_release_driver_internal+0x35c/0x480
[ 677.898461] device_release_driver+0x20/0x38
…
[ 677.912665] —[ end trace 0000000000000000 ]—
CVE-2024-56586
Vie, 27/12/2024 – 15:15
CVE-2024-56586
f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.
creating a large files during checkpoint disable until it runs out of
space and then delete it, then remount to enable checkpoint again, and
then unmount the filesystem triggers the f2fs_bug_on as below:
————[ cut here ]————
kernel BUG at fs/f2fs/inode.c:896!
CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
RIP: 0010:f2fs_evict_inode+0x58c/0x610
Call Trace:
__die_body+0x15/0x60
die+0x33/0x50
do_trap+0x10a/0x120
f2fs_evict_inode+0x58c/0x610
do_error_trap+0x60/0x80
f2fs_evict_inode+0x58c/0x610
exc_invalid_op+0x53/0x60
f2fs_evict_inode+0x58c/0x610
asm_exc_invalid_op+0x16/0x20
f2fs_evict_inode+0x58c/0x610
evict+0x101/0x260
dispose_list+0x30/0x50
evict_inodes+0x140/0x190
generic_shutdown_super+0x2f/0x150
kill_block_super+0x11/0x40
kill_f2fs_super+0x7d/0x140
deactivate_locked_super+0x2a/0x70
cleanup_mnt+0xb3/0x140
task_work_run+0x61/0x90
The root cause is: creating large files during disable checkpoint
period results in not enough free segments, so when writing back root
inode will failed in f2fs_enable_checkpoint. When umount the file
system after enabling checkpoint, the root inode is dirty in
f2fs_evict_inode function, which triggers BUG_ON. The steps to
reproduce are as follows:
dd if=/dev/zero of=f2fs.img bs=1M count=55
mount f2fs.img f2fs_dir -o checkpoint=disable:10%
dd if=/dev/zero of=big bs=1M count=50
sync
rm big
mount -o remount,checkpoint=enable f2fs_dir
umount f2fs_dir
Let's redirty inode when there is not free segments during checkpoint
is disable.