Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/plane: Move range check for format_count earlier<br /> <br /> While the check for format_count &gt; 64 in __drm_universal_plane_init()<br /> shouldn&amp;#39;t be hit (it&amp;#39;s a WARN_ON), in its current position it will then<br /> leak the plane-&gt;format_types array and fail to call<br /> drm_mode_object_unregister() leaking the modeset identifier. Move it to<br /> the start of the function to avoid allocating those resources in the<br /> first place.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix some memory leaks in an error handling path of &amp;#39;log_replay()&amp;#39;<br /> <br /> All error handling paths lead to &amp;#39;out&amp;#39; where many resources are freed.<br /> <br /> Do it as well here instead of a direct return, otherwise &amp;#39;log&amp;#39;, &amp;#39;ra&amp;#39; and<br /> &amp;#39;log-&gt;one_page_buf&amp;#39; (at least) will leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: ir_toy: free before error exiting<br /> <br /> Fix leak in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: staging: media: zoran: move videodev alloc<br /> <br /> Move some code out of zr36057_init() and create new functions for handling<br /> zr-&gt;video_dev. This permit to ease code reading and fix a zr-&gt;video_dev<br /> memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: staging: media: zoran: calculate the right buffer number for zoran_reap_stat_com<br /> <br /> On the case tmp_dcim=1, the index of buffer is miscalculated.<br /> This generate a NULL pointer dereference later.<br /> <br /> So let&amp;#39;s fix the calcul and add a check to prevent this to reappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "Revert "block, bfq: honor already-setup queue merges""<br /> <br /> A crash [1] happened to be triggered in conjunction with commit<br /> 2d52c58b9c9b ("block, bfq: honor already-setup queue merges"). The<br /> latter was then reverted by commit ebc69e897e17 ("Revert "block, bfq:<br /> honor already-setup queue merges""). Yet, the reverted commit was not<br /> the one introducing the bug. In fact, it actually triggered a UAF<br /> introduced by a different commit, and now fixed by commit d29bd41428cf<br /> ("block, bfq: reset last_bfqq_created on group change").<br /> <br /> So, there is no point in keeping commit 2d52c58b9c9b ("block, bfq:<br /> honor already-setup queue merges") out. This commit restores it.<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=214503

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: ipq8074: fix PCI-E clock oops<br /> <br /> Fix PCI-E clock related kernel oops that are caused by a missing clock<br /> parent.<br /> <br /> pcie0_rchng_clk_src has num_parents set to 2 but only one parent is<br /> actually set via parent_hws, it should also have "XO" defined.<br /> This will cause the kernel to panic on a NULL pointer in<br /> clk_core_get_parent_by_index().<br /> <br /> So, to fix this utilize clk_parent_data to provide gcc_xo_gpll0 parent<br /> data.<br /> Since there is already an existing static const char * const gcc_xo_gpll0[]<br /> used to provide the same parents via parent_names convert those users to<br /> clk_parent_data as well.<br /> <br /> Without this earlycon is needed to even catch the OOPS as it will reset<br /> the board before serial is initialized with the following:<br /> <br /> [ 0.232279] Unable to handle kernel paging request at virtual address 0000a00000000000<br /> [ 0.232322] Mem abort info:<br /> [ 0.239094] ESR = 0x96000004<br /> [ 0.241778] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 0.244908] SET = 0, FnV = 0<br /> [ 0.250377] EA = 0, S1PTW = 0<br /> [ 0.253236] FSC = 0x04: level 0 translation fault<br /> [ 0.256277] Data abort info:<br /> [ 0.261141] ISV = 0, ISS = 0x00000004<br /> [ 0.264262] CM = 0, WnR = 0<br /> [ 0.267820] [0000a00000000000] address between user and kernel address ranges<br /> [ 0.270954] Internal error: Oops: 96000004 [#1] SMP<br /> [ 0.278067] Modules linked in:<br /> [ 0.282751] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.10 #0<br /> [ 0.285882] Hardware name: Xiaomi AX3600 (DT)<br /> [ 0.292043] pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.296299] pc : clk_core_get_parent_by_index+0x68/0xec<br /> [ 0.303067] lr : __clk_register+0x1d8/0x820<br /> [ 0.308273] sp : ffffffc01111b7d0<br /> [ 0.312438] x29: ffffffc01111b7d0 x28: 0000000000000000 x27: 0000000000000040<br /> [ 0.315919] x26: 0000000000000002 x25: 0000000000000000 x24: ffffff8000308800<br /> [ 0.323037] x23: ffffff8000308850 x22: ffffff8000308880 x21: ffffff8000308828<br /> [ 0.330155] x20: 0000000000000028 x19: ffffff8000309700 x18: 0000000000000020<br /> [ 0.337272] x17: 000000005cc86990 x16: 0000000000000004 x15: ffffff80001d9d0a<br /> [ 0.344391] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000006<br /> [ 0.351508] x11: 0000000000000003 x10: 0101010101010101 x9 : 0000000000000000<br /> [ 0.358626] x8 : 7f7f7f7f7f7f7f7f x7 : 6468626f5e626266 x6 : 17000a3a403c1b06<br /> [ 0.365744] x5 : 061b3c403a0a0017 x4 : 0000000000000000 x3 : 0000000000000001<br /> [ 0.372863] x2 : 0000a00000000000 x1 : 0000000000000001 x0 : ffffff8000309700<br /> [ 0.379982] Call trace:<br /> [ 0.387091] clk_core_get_parent_by_index+0x68/0xec<br /> [ 0.389351] __clk_register+0x1d8/0x820<br /> [ 0.394210] devm_clk_hw_register+0x5c/0xe0<br /> [ 0.398030] devm_clk_register_regmap+0x44/0x8c<br /> [ 0.402198] qcom_cc_really_probe+0x17c/0x1d0<br /> [ 0.406711] qcom_cc_probe+0x34/0x44<br /> [ 0.411224] gcc_ipq8074_probe+0x18/0x30<br /> [ 0.414869] platform_probe+0x68/0xe0<br /> [ 0.418776] really_probe.part.0+0x9c/0x30c<br /> [ 0.422336] __driver_probe_device+0x98/0x144<br /> [ 0.426329] driver_probe_device+0x44/0x11c<br /> [ 0.430842] __device_attach_driver+0xb4/0x120<br /> [ 0.434836] bus_for_each_drv+0x68/0xb0<br /> [ 0.439349] __device_attach+0xb0/0x170<br /> [ 0.443081] device_initial_probe+0x14/0x20<br /> [ 0.446901] bus_probe_device+0x9c/0xa4<br /> [ 0.451067] device_add+0x35c/0x834<br /> [ 0.454886] of_device_add+0x54/0x64<br /> [ 0.458360] of_platform_device_create_pdata+0xc0/0x100<br /> [ 0.462181] of_platform_bus_create+0x114/0x370<br /> [ 0.467128] of_platform_bus_create+0x15c/0x370<br /> [ 0.471641] of_platform_populate+0x50/0xcc<br /> [ 0.476155] of_platform_default_populate_init+0xa8/0xc8<br /> [ 0.480324] do_one_initcall+0x50/0x1b0<br /> [ 0.485877] kernel_init_freeable+0x234/0x29c<br /> [ 0.489436] kernel_init+0x24/0x120<br /> [ 0.493948] ret_from_fork+0x10/0x20<br /> [ 0.497253] Code: d50323bf d65f03c0 f94002a2 b4000302 (f9400042)<br /> [ 0.501079] ---[ end trace 4ca7e1129da2abce ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpu: host1x: Fix a memory leak in &amp;#39;host1x_remove()&amp;#39;<br /> <br /> Add a missing &amp;#39;host1x_channel_list_free()&amp;#39; call in the remove function,<br /> as already done in the error handling path of the probe function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: validate ubuf-&gt;pagecount<br /> <br /> Syzbot has reported GPF in sg_alloc_append_table_from_pages(). The<br /> problem was in ubuf-&gt;pages == ZERO_PTR.<br /> <br /> ubuf-&gt;pagecount is calculated from arguments passed from user-space. If<br /> user creates udmabuf with list.size == 0 then ubuf-&gt;pagecount will be<br /> also equal to zero; it causes kmalloc_array() to return ZERO_PTR.<br /> <br /> Fix it by validating ubuf-&gt;pagecount before passing it to<br /> kmalloc_array().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: soc-compress: prevent the potentially use of null pointer<br /> <br /> There is one call trace that snd_soc_register_card()<br /> -&gt;snd_soc_bind_card()-&gt;soc_init_pcm_runtime()<br /> -&gt;snd_soc_dai_compress_new()-&gt;snd_soc_new_compress().<br /> In the trace the &amp;#39;codec_dai&amp;#39; transfers from card-&gt;dai_link,<br /> and we can see from the snd_soc_add_pcm_runtime() in<br /> snd_soc_bind_card() that, if value of card-&gt;dai_link-&gt;num_codecs<br /> is 0, then &amp;#39;codec_dai&amp;#39; could be null pointer caused<br /> by index out of bound in &amp;#39;asoc_rtd_to_codec(rtd, 0)&amp;#39;.<br /> And snd_soc_register_card() is called by various platforms.<br /> Therefore, it is better to add the check in the case of misusing.<br /> And because &amp;#39;cpu_dai&amp;#39; has already checked in soc_init_pcm_runtime(),<br /> there is no need to check again.<br /> Adding the check as follow, then if &amp;#39;codec_dai&amp;#39; is null,<br /> snd_soc_new_compress() will not pass through the check<br /> &amp;#39;if (playback + capture != 1)&amp;#39;, avoiding the leftover use of<br /> &amp;#39;codec_dai&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: rpmpd: Check for null return of devm_kcalloc<br /> <br /> Because of the possible failure of the allocation, data-&gt;domains might<br /> be NULL pointer and will cause the dereference of the NULL pointer<br /> later.<br /> Therefore, it might be better to check it and directly return -ENOMEM<br /> without releasing data manually if fails, because the comment of the<br /> devm_kmalloc() says "Memory allocated with this function is<br /> automatically freed on driver detach.".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> video: fbdev: smscufx: Fix null-ptr-deref in ufx_usb_probe()<br /> <br /> I got a null-ptr-deref report:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> RIP: 0010:fb_destroy_modelist+0x38/0x100<br /> ...<br /> Call Trace:<br /> ufx_usb_probe.cold+0x2b5/0xac1 [smscufx]<br /> usb_probe_interface+0x1aa/0x3c0 [usbcore]<br /> really_probe+0x167/0x460<br /> ...<br /> ret_from_fork+0x1f/0x30<br /> <br /> If fb_alloc_cmap() fails in ufx_usb_probe(), fb_destroy_modelist() will<br /> be called to destroy modelist in the error handling path. But modelist<br /> has not been initialized yet, so it will result in null-ptr-deref.<br /> <br /> Initialize modelist before calling fb_alloc_cmap() to fix this bug.