Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall<br /> <br /> If a compat process tries to execute an unknown system call above the<br /> __ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the<br /> offending process. Information about the error is printed to dmesg in<br /> compat_arm_syscall() -&gt; arm64_notify_die() -&gt; arm64_force_sig_fault() -&gt;<br /> arm64_show_signal().<br /> <br /> arm64_show_signal() interprets a non-zero value for<br /> current-&gt;thread.fault_code as an exception syndrome and displays the<br /> message associated with the ESR_ELx.EC field (bits 31:26).<br /> current-&gt;thread.fault_code is set in compat_arm_syscall() -&gt;<br /> arm64_notify_die() with the bad syscall number instead of a valid ESR_ELx<br /> value. This means that the ESR_ELx.EC field has the value that the user set<br /> for the syscall number and the kernel can end up printing bogus exception<br /> messages*. For example, for the syscall number 0x68000000, which evaluates<br /> to ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:<br /> <br /> [ 18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000]<br /> [ 18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79<br /> [ 18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)<br /> [..]<br /> <br /> which is misleading, as the bad compat syscall has nothing to do with<br /> pointer authentication.<br /> <br /> Stop arm64_show_signal() from printing exception syndrome information by<br /> having compat_arm_syscall() set the ESR_ELx value to 0, as it has no<br /> meaning for an invalid system call number. The example above now becomes:<br /> <br /> [ 19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000]<br /> [ 19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80<br /> [ 19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)<br /> [..]<br /> <br /> which although shows less information because the syscall number,<br /> wrongfully advertised as the ESR value, is missing, it is better than<br /> showing plainly wrong information. The syscall number can be easily<br /> obtained with strace.<br /> <br /> *A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative<br /> integer in compat_arm_syscal() and the condition scno

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix resource leak in lpfc_sli4_send_seq_to_ulp()<br /> <br /> If no handler is found in lpfc_complete_unsol_iocb() to match the rctl of a<br /> received frame, the frame is dropped and resources are leaked.<br /> <br /> Fix by returning resources when discarding an unhandled frame type. Update<br /> lpfc_fc_frame_check() handling of NOP basic link service.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: jz4740: Apply DMA engine limits to maximum segment size<br /> <br /> Do what is done in other DMA-enabled MMC host drivers (cf. host/mmci.c) and<br /> limit the maximum segment size based on the DMA engine&amp;#39;s capabilities. This<br /> is needed to avoid warnings like the following with CONFIG_DMA_API_DEBUG=y.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 21 at kernel/dma/debug.c:1162 debug_dma_map_sg+0x2f4/0x39c<br /> DMA-API: jz4780-dma 13420000.dma-controller: mapping sg segment longer than device claims to support [len=98304] [max=65536]<br /> CPU: 0 PID: 21 Comm: kworker/0:1H Not tainted 5.18.0-rc1 #19<br /> Workqueue: kblockd blk_mq_run_work_fn<br /> Stack : 81575aec 00000004 80620000 80620000 80620000 805e7358 00000009 801537ac<br /> 814c832c 806276e3 806e34b4 80620000 81575aec 00000001 81575ab8 09291444<br /> 00000000 00000000 805e7358 81575958 ffffffea 8157596c 00000000 636f6c62<br /> 6220646b 80387a70 0000000f 6d5f6b6c 80620000 00000000 81575ba4 00000009<br /> 805e170c 80896640 00000001 00010000 00000000 00000000 00006098 806e0000<br /> ...<br /> Call Trace:<br /> [] show_stack+0x84/0x120<br /> [] __warn+0xb8/0xec<br /> [] warn_slowpath_fmt+0x6c/0xb8<br /> [] debug_dma_map_sg+0x2f4/0x39c<br /> [] __dma_map_sg_attrs+0xf0/0x118<br /> [] dma_map_sg_attrs+0x14/0x28<br /> [] jz4740_mmc_prepare_dma_data+0x74/0xa4<br /> [] jz4740_mmc_pre_request+0x30/0x54<br /> [] mmc_blk_mq_issue_rq+0x6e0/0x7bc<br /> [] mmc_mq_queue_rq+0x220/0x2d4<br /> [] blk_mq_dispatch_rq_list+0x480/0x664<br /> [] blk_mq_do_dispatch_sched+0x2dc/0x370<br /> [] __blk_mq_sched_dispatch_requests+0xec/0x164<br /> [] blk_mq_sched_dispatch_requests+0x44/0x94<br /> [] __blk_mq_run_hw_queue+0xb0/0xcc<br /> [] process_one_work+0x1b8/0x264<br /> [] worker_thread+0x2ec/0x3b8<br /> [] kthread+0x104/0x10c<br /> [] ret_from_kernel_thread+0x14/0x1c<br /> <br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: cx25821: Fix the warning when removing the module<br /> <br /> When removing the module, we will get the following warning:<br /> <br /> [ 14.746697] remove_proc_entry: removing non-empty directory &amp;#39;irq/21&amp;#39;, leaking at least &amp;#39;cx25821[1]&amp;#39;<br /> [ 14.747449] WARNING: CPU: 4 PID: 368 at fs/proc/generic.c:717 remove_proc_entry+0x389/0x3f0<br /> [ 14.751611] RIP: 0010:remove_proc_entry+0x389/0x3f0<br /> [ 14.759589] Call Trace:<br /> [ 14.759792] <br /> [ 14.759975] unregister_irq_proc+0x14c/0x170<br /> [ 14.760340] irq_free_descs+0x94/0xe0<br /> [ 14.760640] mp_unmap_irq+0xb6/0x100<br /> [ 14.760937] acpi_unregister_gsi_ioapic+0x27/0x40<br /> [ 14.761334] acpi_pci_irq_disable+0x1d3/0x320<br /> [ 14.761688] pci_disable_device+0x1ad/0x380<br /> [ 14.762027] ? _raw_spin_unlock_irqrestore+0x2d/0x60<br /> [ 14.762442] ? cx25821_shutdown+0x20/0x9f0 [cx25821]<br /> [ 14.762848] cx25821_finidev+0x48/0xc0 [cx25821]<br /> [ 14.763242] pci_device_remove+0x92/0x240<br /> <br /> Fix this by freeing the irq before call pci_disable_device().

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: 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 /> 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.

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 /> 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 /> ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with<br /> refcount incremented in this function.<br /> Calling of_node_put() to avoid the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: max9286: fix kernel oops when removing module<br /> <br /> When removing the max9286 module we get a kernel oops:<br /> <br /> Unable to handle kernel paging request at virtual address 000000aa00000094<br /> Mem abort info:<br /> ESR = 0x96000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000<br /> [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec<br /> CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5<br /> Hardware name: Freescale i.MX8QXP MEK (DT)<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : i2c_mux_del_adapters+0x24/0xf0<br /> lr : max9286_remove+0x28/0xd0 [max9286]<br /> sp : ffff800013a9bbf0<br /> x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000<br /> x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8<br /> x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098<br /> x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d<br /> x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000<br /> Call trace:<br /> i2c_mux_del_adapters+0x24/0xf0<br /> max9286_remove+0x28/0xd0 [max9286]<br /> i2c_device_remove+0x40/0x110<br /> __device_release_driver+0x188/0x234<br /> driver_detach+0xc4/0x150<br /> bus_remove_driver+0x60/0xe0<br /> driver_unregister+0x34/0x64<br /> i2c_del_driver+0x58/0xa0<br /> max9286_i2c_driver_exit+0x1c/0x490 [max9286]<br /> __arm64_sys_delete_module+0x194/0x260<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0xd4/0xfc<br /> do_el0_svc+0x2c/0x94<br /> el0_svc+0x28/0x80<br /> el0t_64_sync_handler+0xa8/0x130<br /> el0t_64_sync+0x1a0/0x1a4<br /> <br /> The Oops happens because the I2C client data does not point to<br /> max9286_priv anymore but to v4l2_subdev. The change happened in<br /> max9286_init() which calls v4l2_i2c_subdev_init() later on...<br /> <br /> Besides fixing the max9286_remove() function, remove the call to<br /> i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make<br /> the necessary changes to max9286_init() so that it doesn&amp;#39;t have to use<br /> i2c_get_clientdata() in order to fetch the pointer to priv.

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)