Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/bitmap: don&amp;#39;t set sb values if can&amp;#39;t pass sanity check<br /> <br /> If bitmap area contains invalid data, kernel will crash then mdadm<br /> triggers "Segmentation fault".<br /> This is cluster-md speical bug. In non-clustered env, mdadm will<br /> handle broken metadata case. In clustered array, only kernel space<br /> handles bitmap slot info. But even this bug only happened in clustered<br /> env, current sanity check is wrong, the code should be changed.<br /> <br /> How to trigger: (faulty injection)<br /> <br /> dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sda<br /> dd if=/dev/zero bs=1M count=1 oflag=direct of=/dev/sdb<br /> mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda /dev/sdb<br /> mdadm -Ss<br /> echo aaa &gt; magic.txt<br /> == below modifying slot 2 bitmap data ==<br /> dd if=magic.txt of=/dev/sda seek=16384 bs=1 count=3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi: avoid null dereference in deinit<br /> <br /> If venus_probe fails at pm_runtime_put_sync the error handling first<br /> calls hfi_destroy and afterwards hfi_core_deinit. As hfi_destroy sets<br /> core-&gt;ops to NULL, hfi_core_deinit cannot call the core_deinit function<br /> anymore.<br /> <br /> Avoid this null pointer derefence by skipping the call when necessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: dw9714: Disable the regulator when the driver fails to probe<br /> <br /> When the driver fails to probe, we will get the following splat:<br /> <br /> [ 59.305988] ------------[ cut here ]------------<br /> [ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0<br /> [ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0<br /> [ 59.318362] Call Trace:<br /> [ 59.318582] <br /> [ 59.318765] regulator_put+0x1f/0x30<br /> [ 59.319058] devres_release_group+0x319/0x3d0<br /> [ 59.319420] i2c_device_probe+0x766/0x940<br /> <br /> Fix this by disabling the regulator in error handling.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/pm: fix the null pointer while the smu is disabled<br /> <br /> It needs to check if the pp_funcs is initialized while release the<br /> context, otherwise it will trigger null pointer panic while the software<br /> smu is not enabled.<br /> <br /> [ 1109.404555] BUG: kernel NULL pointer dereference, address: 0000000000000078<br /> [ 1109.404609] #PF: supervisor read access in kernel mode<br /> [ 1109.404638] #PF: error_code(0x0000) - not-present page<br /> [ 1109.404657] PGD 0 P4D 0<br /> [ 1109.404672] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 1109.404701] CPU: 7 PID: 9150 Comm: amdgpu_test Tainted: G OEL 5.16.0-custom #1<br /> [ 1109.404732] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006<br /> [ 1109.404765] RIP: 0010:amdgpu_dpm_force_performance_level+0x1d/0x170 [amdgpu]<br /> [ 1109.405109] Code: 5d c3 44 8b a3 f0 80 00 00 eb e5 66 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 08 4c 8b b7 f0 7d 00 00 83 7e 78 00 0f 84 f2 00 00 00 80 bf 87 80 00 00 00 48 89 fb 0f<br /> [ 1109.405176] RSP: 0018:ffffaf3083ad7c20 EFLAGS: 00010282<br /> [ 1109.405203] RAX: 0000000000000000 RBX: ffff9796b1c14600 RCX: 0000000002862007<br /> [ 1109.405229] RDX: ffff97968591c8c0 RSI: 0000000000000001 RDI: ffff9796a3700000<br /> [ 1109.405260] RBP: ffffaf3083ad7c50 R08: ffffffff9897de00 R09: ffff979688d9db60<br /> [ 1109.405286] R10: 0000000000000000 R11: ffff979688d9db90 R12: 0000000000000001<br /> [ 1109.405316] R13: ffff9796a3700000 R14: 0000000000000000 R15: ffff9796a3708fc0<br /> [ 1109.405345] FS: 00007ff055cff180(0000) GS:ffff9796bfdc0000(0000) knlGS:0000000000000000<br /> [ 1109.405378] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 1109.405400] CR2: 0000000000000078 CR3: 000000000a394000 CR4: 00000000000506e0<br /> [ 1109.405434] Call Trace:<br /> [ 1109.405445] <br /> [ 1109.405456] ? delete_object_full+0x1d/0x20<br /> [ 1109.405480] amdgpu_ctx_set_stable_pstate+0x7c/0xa0 [amdgpu]<br /> [ 1109.405698] amdgpu_ctx_fini.part.0+0xcb/0x100 [amdgpu]<br /> [ 1109.405911] amdgpu_ctx_do_release+0x71/0x80 [amdgpu]<br /> [ 1109.406121] amdgpu_ctx_ioctl+0x52d/0x550 [amdgpu]<br /> [ 1109.406327] ? _raw_spin_unlock+0x1a/0x30<br /> [ 1109.406354] ? drm_gem_handle_delete+0x81/0xb0 [drm]<br /> [ 1109.406400] ? amdgpu_ctx_get_entity+0x2c0/0x2c0 [amdgpu]<br /> [ 1109.406609] drm_ioctl_kernel+0xb6/0x140 [drm]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: fix double free in si_parse_power_table()<br /> <br /> In function si_parse_power_table(), array adev-&gt;pm.dpm.ps and its member<br /> is allocated. If the allocation of each member fails, the array itself<br /> is freed and returned with an error code. However, the array is later<br /> freed again in si_dpm_fini() function which is called when the function<br /> returns an error.<br /> <br /> This leads to potential double free of the array adev-&gt;pm.dpm.ps, as<br /> well as leak of its array members, since the members are not freed in<br /> the allocation function and the array is not nulled when freed.<br /> In addition adev-&gt;pm.dpm.num_ps, which keeps track of the allocated<br /> array member, is not updated until the member allocation is<br /> successfully finished, this could also lead to either use after free,<br /> or uninitialized variable access in si_dpm_fini().<br /> <br /> Fix this by postponing the free of the array until si_dpm_fini() and<br /> increment adev-&gt;pm.dpm.num_ps everytime the array member is allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/omap: fix NULL but dereferenced coccicheck error<br /> <br /> Fix the following coccicheck warning:<br /> ./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl is NULL<br /> but dereferenced.<br /> <br /> Here should be ovl-&gt;idx rather than r_ovl-&gt;idx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: defio: fix the pagelist corruption<br /> <br /> Easily hit the below list corruption:<br /> ==<br /> list_add corruption. prev-&gt;next should be next (ffffffffc0ceb090), but<br /> was ffffec604507edc8. (prev=ffffec604507edc8).<br /> WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26<br /> __list_add_valid+0x53/0x80<br /> CPU: 65 PID: 3959 Comm: fbdev Tainted: G U<br /> RIP: 0010:__list_add_valid+0x53/0x80<br /> Call Trace:<br /> <br /> fb_deferred_io_mkwrite+0xea/0x150<br /> do_page_mkwrite+0x57/0xc0<br /> do_wp_page+0x278/0x2f0<br /> __handle_mm_fault+0xdc2/0x1590<br /> handle_mm_fault+0xdd/0x2c0<br /> do_user_addr_fault+0x1d3/0x650<br /> exc_page_fault+0x77/0x180<br /> ? asm_exc_page_fault+0x8/0x30<br /> asm_exc_page_fault+0x1e/0x30<br /> RIP: 0033:0x7fd98fc8fad1<br /> ==<br /> <br /> Figure out the race happens when one process is adding &amp;page-&gt;lru into<br /> the pagelist tail in fb_deferred_io_mkwrite(), another process is<br /> re-initializing the same &amp;page-&gt;lru in fb_deferred_io_fault(), which is<br /> not protected by the lock.<br /> <br /> This fix is to init all the page lists one time during initialization,<br /> it not only fixes the list corruption, but also avoids INIT_LIST_HEAD()<br /> redundantly.<br /> <br /> V2: change "int i" to "unsigned int i" (Geert Uytterhoeven)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: denali: Use managed device resources<br /> <br /> All of the resources used by this driver has managed interfaces, so use<br /> them. Otherwise we will get the following splat:<br /> <br /> [ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000<br /> [ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5<br /> [ 4.473538] nand: No NAND device found<br /> [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410<br /> [ 4.475169] #PF: supervisor write access in kernel mode<br /> [ 4.475579] #PF: error_code(0x0002) - not-present page<br /> [ 4.478362] RIP: 0010:iowrite32+0x9/0x50<br /> [ 4.486068] Call Trace:<br /> [ 4.486269] <br /> [ 4.486443] denali_isr+0x15b/0x300 [denali]<br /> [ 4.486788] ? denali_direct_write+0x50/0x50 [denali]<br /> [ 4.487189] __handle_irq_event_percpu+0x161/0x3b0<br /> [ 4.487571] handle_irq_event+0x7d/0x1b0<br /> [ 4.487884] handle_fasteoi_irq+0x2b0/0x770<br /> [ 4.488219] __common_interrupt+0xc8/0x1b0<br /> [ 4.488549] common_interrupt+0x9a/0xc0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: governor: Use kobject release() method to free dbs_data<br /> <br /> The struct dbs_data embeds a struct gov_attr_set and<br /> the struct gov_attr_set embeds a kobject. Since every kobject must have<br /> a release() method and we can&amp;#39;t use kfree() to free it directly,<br /> so introduce cpufreq_dbs_data_release() to release the dbs_data via<br /> the kobject::release() method. This fixes the calltrace like below:<br /> <br /> ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34<br /> WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100<br /> Modules linked in:<br /> CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536<br /> Hardware name: Marvell OcteonTX CN96XX board (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : debug_print_object+0xb8/0x100<br /> lr : debug_print_object+0xb8/0x100<br /> sp : ffff80001dfcf9a0<br /> x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000<br /> x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210<br /> x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118<br /> x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000<br /> x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8<br /> x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14<br /> x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0<br /> x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001<br /> x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040<br /> Call trace:<br /> debug_print_object+0xb8/0x100<br /> __debug_check_no_obj_freed+0x1d0/0x25c<br /> debug_check_no_obj_freed+0x24/0xa0<br /> kfree+0x11c/0x440<br /> cpufreq_dbs_governor_exit+0xa8/0xac<br /> cpufreq_exit_governor+0x44/0x90<br /> cpufreq_set_policy+0x29c/0x570<br /> store_scaling_governor+0x110/0x154<br /> store+0xb0/0xe0<br /> sysfs_kf_write+0x58/0x84<br /> kernfs_fop_write_iter+0x12c/0x1c0<br /> new_sync_write+0xf0/0x18c<br /> vfs_write+0x1cc/0x220<br /> ksys_write+0x74/0x100<br /> __arm64_sys_write+0x28/0x3c<br /> invoke_syscall.constprop.0+0x58/0xf0<br /> do_el0_svc+0x70/0x170<br /> el0_svc+0x54/0x190<br /> el0t_64_sync_handler+0xa4/0x130<br /> el0t_64_sync+0x1a0/0x1a4<br /> irq event stamp: 189006<br /> hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0<br /> hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0<br /> softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0<br /> softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4<br /> <br /> [ rjw: Because can be freed by the gov_attr_set_put() in<br /> cpufreq_dbs_governor_exit() now, it is also necessary to put the<br /> invocation of the governor -&gt;exit() callback into the new<br /> cpufreq_dbs_data_release() function. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe<br /> <br /> Call of_node_put(platform_node) to avoid refcount leak in<br /> the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: cs35l41: Fix an out-of-bounds access in otp_packed_element_t<br /> <br /> The CS35L41_NUM_OTP_ELEM is 100, but only 99 entries are defined in<br /> the array otp_map_1/2[CS35L41_NUM_OTP_ELEM], this will trigger UBSAN<br /> to report a shift-out-of-bounds warning in the cs35l41_otp_unpack()<br /> since the last entry in the array will result in GENMASK(-1, 0).<br /> <br /> UBSAN reports this problem:<br /> UBSAN: shift-out-of-bounds in /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8<br /> shift exponent 64 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> CPU: 10 PID: 595 Comm: systemd-udevd Not tainted 5.15.0-23-generic #23<br /> Hardware name: LENOVO \x02MFG_IN_GO/\x02MFG_IN_GO, BIOS N3GET19W (1.00 ) 03/11/2022<br /> Call Trace:<br /> <br /> show_stack+0x52/0x58<br /> dump_stack_lvl+0x4a/0x5f<br /> dump_stack+0x10/0x12<br /> ubsan_epilogue+0x9/0x45<br /> __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef<br /> ? regmap_unlock_mutex+0xe/0x10<br /> cs35l41_otp_unpack.cold+0x1c6/0x2b2 [snd_soc_cs35l41_lib]<br /> cs35l41_hda_probe+0x24f/0x33a [snd_hda_scodec_cs35l41]<br /> cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c]<br /> ? cs35l41_hda_i2c_remove+0x20/0x20 [snd_hda_scodec_cs35l41_i2c]<br /> i2c_device_probe+0x252/0x2b0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: always check VF VSI pointer values<br /> <br /> The ice_get_vf_vsi function can return NULL in some cases, such as if<br /> handling messages during a reset where the VSI is being removed and<br /> recreated.<br /> <br /> Several places throughout the driver do not bother to check whether this<br /> VSI pointer is valid. Static analysis tools maybe report issues because<br /> they detect paths where a potentially NULL pointer could be dereferenced.<br /> <br /> Fix this by checking the return value of ice_get_vf_vsi everywhere.