Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: vector: Fix memory leak in vector_config<br /> <br /> If the return value of the uml_parse_vector_ifspec function is NULL,<br /> we should call kfree(params) to prevent memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio-ap: fix memory leak in vfio_ap device driver<br /> <br /> The device release callback function invoked to release the matrix device<br /> uses the dev_get_drvdata(device *dev) function to retrieve the<br /> pointer to the vfio_matrix_dev object in order to free its storage. The<br /> problem is, this object is not stored as drvdata with the device; since the<br /> kfree function will accept a NULL pointer, the memory for the<br /> vfio_matrix_dev object is never freed.<br /> <br /> Since the device being released is contained within the vfio_matrix_dev<br /> object, the container_of macro will be used to retrieve its pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: verity-loadpin: Only trust verity targets with enforcement<br /> <br /> Verity targets can be configured to ignore corrupted data blocks.<br /> LoadPin must only trust verity targets that are configured to<br /> perform some kind of enforcement when data corruption is detected,<br /> like returning an error, restarting the system or triggering a<br /> panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix potential memory leak in ext4_fc_record_modified_inode()<br /> <br /> As krealloc may return NULL, in this case &amp;#39;state-&gt;fc_modified_inodes&amp;#39;<br /> may not be freed by krealloc, but &amp;#39;state-&gt;fc_modified_inodes&amp;#39; already<br /> set NULL. Then will lead to &amp;#39;state-&gt;fc_modified_inodes&amp;#39; memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: prevent integer overflow in dfl_feature_ioctl_set_irq()<br /> <br /> The "hdr.count * sizeof(s32)" multiplication can overflow on 32 bit<br /> systems leading to memory corruption. Use array_size() to fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: netsec: fix error handling in netsec_register_mdio()<br /> <br /> If phy_device_register() fails, phy_device_free() need be called to<br /> put refcount, so memory of phy device and device name can be freed<br /> in callback function.<br /> <br /> If get_phy_device() fails, mdiobus_unregister() need be called,<br /> or it will cause warning in mdiobus_free() and kobject is leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: amba-pl011: avoid SBSA UART accessing DMACR register<br /> <br /> Chapter "B Generic UART" in "ARM Server Base System Architecture" [1]<br /> documentation describes a generic UART interface. Such generic UART<br /> does not support DMA. In current code, sbsa_uart_pops and<br /> amba_pl011_pops share the same stop_rx operation, which will invoke<br /> pl011_dma_rx_stop, leading to an access of the DMACR register. This<br /> commit adds a using_rx_dma check in pl011_dma_rx_stop to avoid the<br /> access to DMACR register for SBSA UARTs which does not support DMA.<br /> <br /> When the kernel enables DMA engine with "CONFIG_DMA_ENGINE=y", Linux<br /> SBSA PL011 driver will access PL011 DMACR register in some functions.<br /> For most real SBSA Pl011 hardware implementations, the DMACR write<br /> behaviour will be ignored. So these DMACR operations will not cause<br /> obvious problems. But for some virtual SBSA PL011 hardware, like Xen<br /> virtual SBSA PL011 (vpl011) device, the behaviour might be different.<br /> Xen vpl011 emulation will inject a data abort to guest, when guest is<br /> accessing an unimplemented UART register. As Xen VPL011 is SBSA<br /> compatible, it will not implement DMACR register. So when Linux SBSA<br /> PL011 driver access DMACR register, it will get an unhandled data abort<br /> fault and the application will get a segmentation fault:<br /> Unhandled fault at 0xffffffc00944d048<br /> Mem abort info:<br /> ESR = 0x96000000<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x00: ttbr address size fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000000<br /> CM = 0, WnR = 0<br /> swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000020e2e000<br /> [ffffffc00944d048] pgd=100000003ffff803, p4d=100000003ffff803, pud=100000003ffff803, pmd=100000003fffa803, pte=006800009c090f13<br /> Internal error: ttbr address size fault: 96000000 [#1] PREEMPT SMP<br /> ...<br /> Call trace:<br /> pl011_stop_rx+0x70/0x80<br /> tty_port_shutdown+0x7c/0xb4<br /> tty_port_close+0x60/0xcc<br /> uart_close+0x34/0x8c<br /> tty_release+0x144/0x4c0<br /> __fput+0x78/0x220<br /> ____fput+0x1c/0x30<br /> task_work_run+0x88/0xc0<br /> do_notify_resume+0x8d0/0x123c<br /> el0_svc+0xa8/0xc0<br /> el0t_64_sync_handler+0xa4/0x130<br /> el0t_64_sync+0x1a0/0x1a4<br /> Code: b9000083 b901f001 794038a0 8b000042 (b9000041)<br /> ---[ end trace 83dd93df15c3216f ]---<br /> note: bootlogd[132] exited with preempt_count 1<br /> /etc/rcS.d/S07bootlogd: line 47: 132 Segmentation fault start-stop-daemon<br /> <br /> This has been discussed in the Xen community, and we think it should fix<br /> this in Linux. See [2] for more information.<br /> <br /> [1] https://developer.arm.com/documentation/den0094/c/?lang=en<br /> [2] https://lists.xenproject.org/archives/html/xen-devel/2022-11/msg00543.html

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: fix memory leak in dvb_usb_adapter_init()<br /> <br /> Syzbot reports a memory leak in "dvb_usb_adapter_init()".<br /> The leak is due to not accounting for and freeing current iteration&amp;#39;s<br /> adapter-&gt;priv in case of an error. Currently if an error occurs,<br /> it will exit before incrementing "num_adapters_initalized",<br /> which is used as a reference counter to free all adap-&gt;priv<br /> in "dvb_usb_adapter_exit()". There are multiple error paths that<br /> can exit from before incrementing the counter. Including the<br /> error handling paths for "dvb_usb_adapter_stream_init()",<br /> "dvb_usb_adapter_dvb_init()" and "dvb_usb_adapter_frontend_init()"<br /> within "dvb_usb_adapter_init()".<br /> <br /> This means that in case of an error in any of these functions the<br /> current iteration is not accounted for and the current iteration&amp;#39;s<br /> adap-&gt;priv is not freed.<br /> <br /> Fix this by freeing the current iteration&amp;#39;s adap-&gt;priv in the<br /> "stream_init_err:" label in the error path. The rest of the<br /> (accounted for) adap-&gt;priv objects are freed in dvb_usb_adapter_exit()<br /> as expected using the num_adapters_initalized variable.<br /> <br /> Syzbot report:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xffff8881172f1a00 (size 512):<br /> comm "kworker/0:2", pid 139, jiffies 4294994873 (age 10.960s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:75 [inline]<br /> [] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:184 [inline]<br /> [] dvb_usb_device_init.cold+0x4e5/0x79e drivers/media/usb/dvb-usb/dvb-usb-init.c:308<br /> [] dib0700_probe+0x8d/0x1b0 drivers/media/usb/dvb-usb/dib0700_core.c:883<br /> [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396<br /> [] call_driver_probe drivers/base/dd.c:542 [inline]<br /> [] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621<br /> [] really_probe drivers/base/dd.c:583 [inline]<br /> [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752<br /> [] driver_probe_device+0x2a/0x120 drivers/base/dd.c:782<br /> [] __device_attach_driver+0xf6/0x140 drivers/base/dd.c:899<br /> [] bus_for_each_drv+0xb7/0x100 drivers/base/bus.c:427<br /> [] __device_attach+0x122/0x260 drivers/base/dd.c:970<br /> [] bus_probe_device+0xc6/0xe0 drivers/base/bus.c:487<br /> [] device_add+0x5fb/0xdf0 drivers/base/core.c:3405<br /> [] usb_set_configuration+0x8f2/0xb80 drivers/usb/core/message.c:2170<br /> [] usb_generic_driver_probe+0x8c/0xc0 drivers/usb/core/generic.c:238<br /> [] usb_probe_device+0x5c/0x140 drivers/usb/core/driver.c:293<br /> [] call_driver_probe drivers/base/dd.c:542 [inline]<br /> [] really_probe.part.0+0xe7/0x310 drivers/base/dd.c:621<br /> [] really_probe drivers/base/dd.c:583 [inline]<br /> [] __driver_probe_device+0x10c/0x1e0 drivers/base/dd.c:752

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix monitor mode bringup crash<br /> <br /> When the interface is brought up in monitor mode, it leads<br /> to NULL pointer dereference crash. This crash happens when<br /> the packet type is extracted for a SKB. This extraction<br /> which is present in the received msdu delivery path,is<br /> not needed for the monitor ring packets since they are<br /> all RAW packets. Hence appending the flags with<br /> "RX_FLAG_ONLY_MONITOR" to skip that extraction.<br /> <br /> Observed calltrace:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000064<br /> Mem abort info:<br /> ESR = 0x0000000096000004<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=0000000048517000<br /> [0000000000000064] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> Modules linked in: ath11k_pci ath11k qmi_helpers<br /> CPU: 2 PID: 1781 Comm: napi/-271 Not tainted<br /> 6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6<br /> Hardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]<br /> lr : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k]<br /> sp : ffff80000ef5bb10<br /> x29: ffff80000ef5bb10 x28: 0000000000000000 x27: ffff000007baafa0<br /> x26: ffff000014a91ed0 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600<br /> x20: 0000000000000000 x19: ffff800002b77740 x18: 0000000000000006<br /> x17: 736564203634343a x16: 656e694c20657079 x15: 0000000000000143<br /> x14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8<br /> x11: ffff80000a591d30 x10: ffff80000a579d40 x9 : c0000000ffffefff<br /> x8 : 0000000000000003 x7 : 0000000000017fe8 x6 : ffff80000a579ce8<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 3a35ec12ed7f8900 x1 : 0000000000000000 x0 : 0000000000000052<br /> Call trace:<br /> ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]<br /> ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k]<br /> ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k]<br /> ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k]<br /> ath11k_dp_service_srng+0x234/0x338 [ath11k]<br /> ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]<br /> __napi_poll+0x5c/0x190<br /> napi_threaded_poll+0xf0/0x118<br /> kthread+0xf4/0x110<br /> ret_from_fork+0x10/0x20<br /> <br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gud: Fix UBSAN warning<br /> <br /> UBSAN complains about invalid value for bool:<br /> <br /> [ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1<br /> [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device<br /> [ 101.213426] usbcore: registered new interface driver gud<br /> [ 101.989431] ================================================================================<br /> [ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9<br /> [ 101.989447] load of value 121 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3<br /> [ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018<br /> [ 101.989459] Workqueue: events_long gud_flush_work [gud]<br /> [ 101.989471] Call Trace:<br /> [ 101.989474] <br /> [ 101.989479] dump_stack_lvl+0x49/0x5f<br /> [ 101.989488] dump_stack+0x10/0x12<br /> [ 101.989493] ubsan_epilogue+0x9/0x3b<br /> [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49<br /> [ 101.989504] dma_buf_vmap.cold+0x38/0x3d<br /> [ 101.989511] ? find_busiest_group+0x48/0x300<br /> [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper]<br /> [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper]<br /> [ 101.989535] drm_gem_vmap+0x26/0x60 [drm]<br /> [ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper]<br /> [ 101.989630] gud_prep_flush+0xc1/0x710 [gud]<br /> [ 101.989639] ? _raw_spin_lock+0x17/0x40<br /> [ 101.989648] gud_flush_work+0x1e0/0x430 [gud]<br /> [ 101.989653] ? __switch_to+0x11d/0x470<br /> [ 101.989664] process_one_work+0x21f/0x3f0<br /> [ 101.989673] worker_thread+0x200/0x3e0<br /> [ 101.989679] ? rescuer_thread+0x390/0x390<br /> [ 101.989684] kthread+0xfd/0x130<br /> [ 101.989690] ? kthread_complete_and_exit+0x20/0x20<br /> [ 101.989696] ret_from_fork+0x22/0x30<br /> [ 101.989706] <br /> [ 101.989708] ================================================================================<br /> <br /> The source of this warning is in iosys_map_clear() called from<br /> dma_buf_vmap(). It conditionally sets values based on map-&gt;is_iomem. The<br /> iosys_map variables are allocated uninitialized on the stack leading to<br /> -&gt;is_iomem having all kinds of values and not only 0/1.<br /> <br /> Fix this by zeroing the iosys_map variables.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: pci_endpoint_test: Fix pci_endpoint_test_{copy,write,read}() panic<br /> <br /> The dma_map_single() doesn&amp;#39;t permit zero length mapping. It causes a follow<br /> panic.<br /> <br /> A panic was reported on arm64:<br /> <br /> [ 60.137988] ------------[ cut here ]------------<br /> [ 60.142630] kernel BUG at kernel/dma/swiotlb.c:624!<br /> [ 60.147508] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP<br /> [ 60.152992] Modules linked in: dw_hdmi_cec crct10dif_ce simple_bridge rcar_fdp1 vsp1 rcar_vin videobuf2_vmalloc rcar_csi2 v4l<br /> 2_mem2mem videobuf2_dma_contig videobuf2_memops pci_endpoint_test videobuf2_v4l2 videobuf2_common rcar_fcp v4l2_fwnode v4l2_asyn<br /> c videodev mc gpio_bd9571mwv max9611 pwm_rcar ccree at24 authenc libdes phy_rcar_gen3_usb3 usb_dmac display_connector pwm_bl<br /> [ 60.186252] CPU: 0 PID: 508 Comm: pcitest Not tainted 6.0.0-rc1rpci-dev+ #237<br /> [ 60.193387] Hardware name: Renesas Salvator-X 2nd version board based on r8a77951 (DT)<br /> [ 60.201302] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 60.208263] pc : swiotlb_tbl_map_single+0x2c0/0x590<br /> [ 60.213149] lr : swiotlb_map+0x88/0x1f0<br /> [ 60.216982] sp : ffff80000a883bc0<br /> [ 60.220292] x29: ffff80000a883bc0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 60.227430] x26: 0000000000000000 x25: ffff0004c0da20d0 x24: ffff80000a1f77c0<br /> [ 60.234567] x23: 0000000000000002 x22: 0001000040000010 x21: 000000007a000000<br /> [ 60.241703] x20: 0000000000200000 x19: 0000000000000000 x18: 0000000000000000<br /> [ 60.248840] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0006ff7b9180<br /> [ 60.255977] x14: ffff0006ff7b9180 x13: 0000000000000000 x12: 0000000000000000<br /> [ 60.263113] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> [ 60.270249] x8 : 0001000000000010 x7 : ffff0004c6754b20 x6 : 0000000000000000<br /> [ 60.277385] x5 : ffff0004c0da2090 x4 : 0000000000000000 x3 : 0000000000000001<br /> [ 60.284521] x2 : 0000000040000000 x1 : 0000000000000000 x0 : 0000000040000010<br /> [ 60.291658] Call trace:<br /> [ 60.294100] swiotlb_tbl_map_single+0x2c0/0x590<br /> [ 60.298629] swiotlb_map+0x88/0x1f0<br /> [ 60.302115] dma_map_page_attrs+0x188/0x230<br /> [ 60.306299] pci_endpoint_test_ioctl+0x5e4/0xd90 [pci_endpoint_test]<br /> [ 60.312660] __arm64_sys_ioctl+0xa8/0xf0<br /> [ 60.316583] invoke_syscall+0x44/0x108<br /> [ 60.320334] el0_svc_common.constprop.0+0xcc/0xf0<br /> [ 60.325038] do_el0_svc+0x2c/0xb8<br /> [ 60.328351] el0_svc+0x2c/0x88<br /> [ 60.331406] el0t_64_sync_handler+0xb8/0xc0<br /> [ 60.335587] el0t_64_sync+0x18c/0x190<br /> [ 60.339251] Code: 52800013 d2e00414 35fff45c d503201f (d4210000)<br /> [ 60.345344] ---[ end trace 0000000000000000 ]---<br /> <br /> To fix it, this patch adds a checking the payload length if it is zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/uncore: Fix reference count leak in snr_uncore_mmio_map()<br /> <br /> pci_get_device() will increase the reference count for the returned<br /> pci_dev, so snr_uncore_get_mc_dev() will return a pci_dev with its<br /> reference count increased. We need to call pci_dev_put() to decrease the<br /> reference count. Let&amp;#39;s add the missing pci_dev_put().