Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.<br /> <br /> creating a large files during checkpoint disable until it runs out of<br /> space and then delete it, then remount to enable checkpoint again, and<br /> then unmount the filesystem triggers the f2fs_bug_on as below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/inode.c:896!<br /> CPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:f2fs_evict_inode+0x58c/0x610<br /> Call Trace:<br /> __die_body+0x15/0x60<br /> die+0x33/0x50<br /> do_trap+0x10a/0x120<br /> f2fs_evict_inode+0x58c/0x610<br /> do_error_trap+0x60/0x80<br /> f2fs_evict_inode+0x58c/0x610<br /> exc_invalid_op+0x53/0x60<br /> f2fs_evict_inode+0x58c/0x610<br /> asm_exc_invalid_op+0x16/0x20<br /> f2fs_evict_inode+0x58c/0x610<br /> evict+0x101/0x260<br /> dispose_list+0x30/0x50<br /> evict_inodes+0x140/0x190<br /> generic_shutdown_super+0x2f/0x150<br /> kill_block_super+0x11/0x40<br /> kill_f2fs_super+0x7d/0x140<br /> deactivate_locked_super+0x2a/0x70<br /> cleanup_mnt+0xb3/0x140<br /> task_work_run+0x61/0x90<br /> <br /> The root cause is: creating large files during disable checkpoint<br /> period results in not enough free segments, so when writing back root<br /> inode will failed in f2fs_enable_checkpoint. When umount the file<br /> system after enabling checkpoint, the root inode is dirty in<br /> f2fs_evict_inode function, which triggers BUG_ON. The steps to<br /> reproduce are as follows:<br /> <br /> dd if=/dev/zero of=f2fs.img bs=1M count=55<br /> mount f2fs.img f2fs_dir -o checkpoint=disable:10%<br /> dd if=/dev/zero of=big bs=1M count=50<br /> sync<br /> rm big<br /> mount -o remount,checkpoint=enable f2fs_dir<br /> umount f2fs_dir<br /> <br /> Let&amp;#39;s redirty inode when there is not free segments during checkpoint<br /> is disable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> leds: class: Protect brightness_show() with led_cdev-&gt;led_access mutex<br /> <br /> There is NULL pointer issue observed if from Process A where hid device<br /> being added which results in adding a led_cdev addition and later a<br /> another call to access of led_cdev attribute from Process B can result<br /> in NULL pointer issue.<br /> <br /> Use mutex led_cdev-&gt;led_access to protect access to led-&gt;cdev and its<br /> attribute inside brightness_show() and max_brightness_show() and also<br /> update the comment for mutex that it should be used to protect the led<br /> class device fields.<br /> <br /> Process A Process B<br /> <br /> kthread+0x114<br /> worker_thread+0x244<br /> process_scheduled_works+0x248<br /> uhid_device_add_worker+0x24<br /> hid_add_device+0x120<br /> device_add+0x268<br /> bus_probe_device+0x94<br /> device_initial_probe+0x14<br /> __device_attach+0xfc<br /> bus_for_each_drv+0x10c<br /> __device_attach_driver+0x14c<br /> driver_probe_device+0x3c<br /> __driver_probe_device+0xa0<br /> really_probe+0x190<br /> hid_device_probe+0x130<br /> ps_probe+0x990<br /> ps_led_register+0x94<br /> devm_led_classdev_register_ext+0x58<br /> led_classdev_register_ext+0x1f8<br /> device_create_with_groups+0x48<br /> device_create_groups_vargs+0xc8<br /> device_add+0x244<br /> kobject_uevent+0x14<br /> kobject_uevent_env[jt]+0x224<br /> mutex_unlock[jt]+0xc4<br /> __mutex_unlock_slowpath+0xd4<br /> wake_up_q+0x70<br /> try_to_wake_up[jt]+0x48c<br /> preempt_schedule_common+0x28<br /> __schedule+0x628<br /> __switch_to+0x174<br /> el0t_64_sync+0x1a8/0x1ac<br /> el0t_64_sync_handler+0x68/0xbc<br /> el0_svc+0x38/0x68<br /> do_el0_svc+0x1c/0x28<br /> el0_svc_common+0x80/0xe0<br /> invoke_syscall+0x58/0x114<br /> __arm64_sys_read+0x1c/0x2c<br /> ksys_read+0x78/0xe8<br /> vfs_read+0x1e0/0x2c8<br /> kernfs_fop_read_iter+0x68/0x1b4<br /> seq_read_iter+0x158/0x4ec<br /> kernfs_seq_show+0x44/0x54<br /> sysfs_kf_seq_show+0xb4/0x130<br /> dev_attr_show+0x38/0x74<br /> brightness_show+0x20/0x4c<br /> dualshock4_led_get_brightness+0xc/0x74<br /> <br /> [ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060<br /> [ 3313.874301][ T4013] Mem abort info:<br /> [ 3313.874303][ T4013] ESR = 0x0000000096000006<br /> [ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 3313.874307][ T4013] SET = 0, FnV = 0<br /> [ 3313.874309][ T4013] EA = 0, S1PTW = 0<br /> [ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault<br /> [ 3313.874313][ T4013] Data abort info:<br /> [ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000<br /> [ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000<br /> ..<br /> <br /> [ 3313.874332][ T4013] Dumping ftrace buffer:<br /> [ 3313.874334][ T4013] (ftrace buffer empty)<br /> ..<br /> ..<br /> [ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader<br /> [ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74<br /> [ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60<br /> [ 3313.874656][ T4013] sp : ffffffc0b910bbd0<br /> ..<br /> ..<br /> [ 3313.874685][ T4013] Call trace:<br /> [ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74<br /> [ 3313.874690][ T4013] brightness_show+0x20/0x4c<br /> [ 3313.874692][ T4013] dev_attr_show+0x38/0x74<br /> [ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130<br /> [ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54<br /> [ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec<br /> [ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4<br /> [ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8<br /> [ 3313.874711][ T4013] ksys_read+0x78/0xe8<br /> [ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c<br /> [ 3313.874718][ T4013] invoke_syscall+0x58/0x114<br /> [ 3313.874721][ T4013] el0_svc_common+0x80/0xe0<br /> [ 3313.874724][ T4013] do_el0_svc+0x1c/0x28<br /> [ 3313.874727][ T4013] el0_svc+0x38/0x68<br /> [ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc<br /> [ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/tctx: work around xa_store() allocation error issue<br /> <br /> syzbot triggered the following WARN_ON:<br /> <br /> WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51<br /> <br /> which is the<br /> <br /> WARN_ON_ONCE(!xa_empty(&amp;tctx-&gt;xa));<br /> <br /> sanity check in __io_uring_free() when a io_uring_task is going through<br /> its final put. The syzbot test case includes injecting memory allocation<br /> failures, and it very much looks like xa_store() can fail one of its<br /> memory allocations and end up with -&gt;head being non-NULL even though no<br /> entries exist in the xarray.<br /> <br /> Until this issue gets sorted out, work around it by attempting to<br /> iterate entries in our xarray, and WARN_ON_ONCE() if one is found.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi/libstub: Free correct pointer on failure<br /> <br /> cmdline_ptr is an out parameter, which is not allocated by the function<br /> itself, and likely points into the caller&amp;#39;s stack.<br /> <br /> cmdline refers to the pool allocation that should be freed when cleaning<br /> up after a failure, so pass this instead to free_pool().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mtk-jpeg: Fix null-ptr-deref during unload module<br /> <br /> The workqueue should be destroyed in mtk_jpeg_core.c since commit<br /> 09aea13ecf6f ("media: mtk-jpeg: refactor some variables"), otherwise<br /> the below calltrace can be easily triggered.<br /> <br /> [ 677.862514] Unable to handle kernel paging request at virtual address dfff800000000023<br /> [ 677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> ...<br /> [ 677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G O 6.8.12-mtk+gfa1a78e5d24b+ #17<br /> ...<br /> [ 677.882838] pc : destroy_workqueue+0x3c/0x770<br /> [ 677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]<br /> [ 677.884314] sp : ffff80008ad974f0<br /> [ 677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070<br /> [ 677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690<br /> [ 677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000<br /> [ 677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0<br /> [ 677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10<br /> [ 677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d<br /> [ 677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90<br /> [ 677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001<br /> [ 677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000<br /> [ 677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118<br /> [ 677.893977] Call trace:<br /> [ 677.894297] destroy_workqueue+0x3c/0x770<br /> [ 677.894826] mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]<br /> [ 677.895677] devm_action_release+0x50/0x90<br /> [ 677.896211] release_nodes+0xe8/0x170<br /> [ 677.896688] devres_release_all+0xf8/0x178<br /> [ 677.897219] device_unbind_cleanup+0x24/0x170<br /> [ 677.897785] device_release_driver_internal+0x35c/0x480<br /> [ 677.898461] device_release_driver+0x20/0x38<br /> ...<br /> [ 677.912665] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()<br /> <br /> The buffer in the loop should be released under the exception path,<br /> otherwise there may be a memory leak here.<br /> <br /> To mitigate this, free the buffer when allegro_alloc_buffer fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ts2020: fix null-ptr-deref in ts2020_probe()<br /> <br /> KASAN reported a null-ptr-deref issue when executing the following<br /> command:<br /> <br /> # echo ts2020 0x20 &gt; /sys/bus/i2c/devices/i2c-0/new_device<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)<br /> RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]<br /> RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809<br /> RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010<br /> RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6<br /> R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790<br /> R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001<br /> FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ts2020_probe+0xad/0xe10 [ts2020]<br /> i2c_device_probe+0x421/0xb40<br /> really_probe+0x266/0x850<br /> ...<br /> <br /> The cause of the problem is that when using sysfs to dynamically register<br /> an i2c device, there is no platform data, but the probe process of ts2020<br /> needs to use platform data, resulting in a null pointer being accessed.<br /> <br /> Solve this problem by adding checks to platform data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Ensure power suppliers be suspended before detach them<br /> <br /> The power suppliers are always requested to suspend asynchronously,<br /> dev_pm_domain_detach() requires the caller to ensure proper<br /> synchronization of this function with power management callbacks.<br /> otherwise the detach may led to kernel panic, like below:<br /> <br /> [ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040<br /> [ 1457.116777] Mem abort info:<br /> [ 1457.119589] ESR = 0x0000000096000004<br /> [ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 1457.128692] SET = 0, FnV = 0<br /> [ 1457.131764] EA = 0, S1PTW = 0<br /> [ 1457.134920] FSC = 0x04: level 0 translation fault<br /> [ 1457.139812] Data abort info:<br /> [ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000<br /> [ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000<br /> [ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> [ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec]<br /> [ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66<br /> [ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)<br /> [ 1457.199236] Workqueue: pm pm_runtime_work<br /> [ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290<br /> [ 1457.214886] lr : __rpm_callback+0x48/0x1d8<br /> [ 1457.218968] sp : ffff80008250bc50<br /> [ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000<br /> [ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240<br /> [ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008<br /> [ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff<br /> [ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674<br /> [ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002<br /> [ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0<br /> [ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000<br /> [ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000<br /> [ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000<br /> [ 1457.293510] Call trace:<br /> [ 1457.295946] genpd_runtime_suspend+0x20/0x290<br /> [ 1457.300296] __rpm_callback+0x48/0x1d8<br /> [ 1457.304038] rpm_callback+0x6c/0x78<br /> [ 1457.307515] rpm_suspend+0x10c/0x570<br /> [ 1457.311077] pm_runtime_work+0xc4/0xc8<br /> [ 1457.314813] process_one_work+0x138/0x248<br /> [ 1457.318816] worker_thread+0x320/0x438<br /> [ 1457.322552] kthread+0x110/0x114<br /> [ 1457.325767] ret_from_fork+0x10/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: tc358743: Fix crash in the probe error path when using polling<br /> <br /> If an error occurs in the probe() function, we should remove the polling<br /> timer that was alarmed earlier, otherwise the timer is called with<br /> arguments that are already freed, which results in a crash.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226<br /> Hardware name: Diasom DS-RK3568-SOM-EVB (DT)<br /> pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __run_timers+0x244/0x268<br /> lr : __run_timers+0x1d4/0x268<br /> sp : ffffff80eff2baf0<br /> x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00<br /> x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00<br /> x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000<br /> x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffff<br /> x17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003e<br /> x14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000<br /> x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009<br /> x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480<br /> x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240<br /> x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0<br /> Call trace:<br />  __run_timers+0x244/0x268<br />  timer_expire_remote+0x50/0x68<br />  tmigr_handle_remote+0x388/0x39c<br />  run_timer_softirq+0x38/0x44<br />  handle_softirqs+0x138/0x298<br />  __do_softirq+0x14/0x20<br />  ____do_softirq+0x10/0x1c<br />  call_on_irq_stack+0x24/0x4c<br />  do_softirq_own_stack+0x1c/0x2c<br />  irq_exit_rcu+0x9c/0xcc<br />  el1_interrupt+0x48/0xc0<br />  el1h_64_irq_handler+0x18/0x24<br />  el1h_64_irq+0x7c/0x80<br />  default_idle_call+0x34/0x68<br />  do_idle+0x23c/0x294<br />  cpu_startup_entry+0x38/0x3c<br />  secondary_start_kernel+0x128/0x160<br />  __secondary_switched+0xb8/0xbc<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: imx-jpeg: Set video drvdata before register video device<br /> <br /> The video drvdata should be set before the video device is registered,<br /> otherwise video_drvdata() may return NULL in the open() file ops, and led<br /> to oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: amphion: Set video drvdata before register video device<br /> <br /> The video drvdata should be set before the video device is registered,<br /> otherwise video_drvdata() may return NULL in the open() file ops, and led<br /> to oops.