Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: zr364xx: fix memory leak in zr364xx_start_readpipe<br /> <br /> syzbot reported memory leak in zr364xx driver.<br /> The problem was in non-freed urb in case of<br /> usb_submit_urb() fail.<br /> <br /> backtrace:<br /> [] kmalloc include/linux/slab.h:561 [inline]<br /> [] usb_alloc_urb+0x66/0xe0 drivers/usb/core/urb.c:74<br /> [] zr364xx_start_readpipe+0x78/0x130 drivers/media/usb/zr364xx/zr364xx.c:1022<br /> [] zr364xx_board_init drivers/media/usb/zr364xx/zr364xx.c:1383 [inline]<br /> [] zr364xx_probe+0x6a3/0x851 drivers/media/usb/zr364xx/zr364xx.c:1516<br /> [] usb_probe_interface+0x177/0x370 drivers/usb/core/driver.c:396<br /> [] really_probe+0x159/0x500 drivers/base/dd.c:576

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Fix rdma_resolve_route() memory leak<br /> <br /> Fix a memory leak when "mda_resolve_route() is called more than once on<br /> the same "rdma_cm_id".<br /> <br /> This is possible if cma_query_handler() triggers the<br /> RDMA_CM_EVENT_ROUTE_ERROR flow which puts the state machine back and<br /> allows rdma_resolve_route() to be called again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()<br /> <br /> commit 6f755e85c332 ("coresight: Add helper for inserting synchronization<br /> packets") removed trailing &amp;#39;\0&amp;#39; from barrier_pkt array and updated the<br /> call sites like etb_update_buffer() to have proper checks for barrier_pkt<br /> size before read but missed updating tmc_update_etf_buffer() which still<br /> reads barrier_pkt past the array size resulting in KASAN out-of-bounds<br /> bug. Fix this by adding a check for barrier_pkt size before accessing<br /> like it is done in etb_update_buffer().<br /> <br /> BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698<br /> Read of size 4 at addr ffffffd05b7d1030 by task perf/2629<br /> <br /> Call trace:<br /> dump_backtrace+0x0/0x27c<br /> show_stack+0x20/0x2c<br /> dump_stack+0x11c/0x188<br /> print_address_description+0x3c/0x4a4<br /> __kasan_report+0x140/0x164<br /> kasan_report+0x10/0x18<br /> __asan_report_load4_noabort+0x1c/0x24<br /> tmc_update_etf_buffer+0x4b8/0x698<br /> etm_event_stop+0x248/0x2d8<br /> etm_event_del+0x20/0x2c<br /> event_sched_out+0x214/0x6f0<br /> group_sched_out+0xd0/0x270<br /> ctx_sched_out+0x2ec/0x518<br /> __perf_event_task_sched_out+0x4fc/0xe6c<br /> __schedule+0x1094/0x16a0<br /> preempt_schedule_irq+0x88/0x170<br /> arm64_preempt_schedule_irq+0xf0/0x18c<br /> el1_irq+0xe8/0x180<br /> perf_event_exec+0x4d8/0x56c<br /> setup_new_exec+0x204/0x400<br /> load_elf_binary+0x72c/0x18c0<br /> search_binary_handler+0x13c/0x420<br /> load_script+0x500/0x6c4<br /> search_binary_handler+0x13c/0x420<br /> exec_binprm+0x118/0x654<br /> __do_execve_file+0x77c/0xba4<br /> __arm64_compat_sys_execve+0x98/0xac<br /> el0_svc_common+0x1f8/0x5e0<br /> el0_svc_compat_handler+0x84/0xb0<br /> el0_svc_compat+0x10/0x50<br /> <br /> The buggy address belongs to the variable:<br /> barrier_pkt+0x10/0x40<br /> <br /> Memory state around the buggy address:<br /> ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00<br /> ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03<br /> ^<br /> ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa<br /> ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wl1251: Fix possible buffer overflow in wl1251_cmd_scan<br /> <br /> Function wl1251_cmd_scan calls memcpy without checking the length.<br /> Harden by checking the length is within the maximum allowed size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Avoid HDCP over-read and corruption<br /> <br /> Instead of reading the desired 5 bytes of the actual target field,<br /> the code was reading 8. This could result in a corrupted value if the<br /> trailing 3 bytes were non-zero, so instead use an appropriately sized<br /> and zero-initialized bounce buffer, and read only 5 bytes before casting<br /> to u64.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: Add validation for used length<br /> <br /> This adds validation for used length (might come<br /> from an untrusted device) to avoid data corruption<br /> or loss.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: common: usb-conn-gpio: fix NULL pointer dereference of charger<br /> <br /> When power on system with OTG cable, IDDIG&amp;#39;s interrupt arises before<br /> the charger registration, it will cause a NULL pointer dereference,<br /> fix the issue by registering the power supply before requesting<br /> IDDIG/VBUS irq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: Don&amp;#39;t call free_pages_exact() with NULL address<br /> <br /> Unlike some other functions, we can&amp;#39;t pass NULL pointer to<br /> free_pages_exact(). Add a proper NULL check for avoiding possible<br /> Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge<br /> <br /> There is an issue with the ASPM(optional) capability checking function.<br /> A device might be attached to root complex directly, in this case,<br /> bus-&gt;self(bridge) will be NULL, thus priv-&gt;parent_pdev is NULL.<br /> Since alcor_pci_init_check_aspm(priv-&gt;parent_pdev) checks the PCI link&amp;#39;s<br /> ASPM capability and populate parent_cap_off, which will be used later by<br /> alcor_pci_aspm_ctrl() to dynamically turn on/off device, what we can do<br /> here is to avoid checking the capability if we are on the root complex.<br /> This will make pdev_cap_off 0 and alcor_pci_aspm_ctrl() will simply<br /> return when bring called, effectively disable ASPM for the device.<br /> <br /> [ 1.246492] BUG: kernel NULL pointer dereference, address: 00000000000000c0<br /> [ 1.248731] RIP: 0010:pci_read_config_byte+0x5/0x40<br /> [ 1.253998] Call Trace:<br /> [ 1.254131] ? alcor_pci_find_cap_offset.isra.0+0x3a/0x100 [alcor_pci]<br /> [ 1.254476] alcor_pci_probe+0x169/0x2d5 [alcor_pci]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc/libmasm/module: Fix two use after free in ibmasm_init_one<br /> <br /> In ibmasm_init_one, it calls ibmasm_init_remote_input_dev().<br /> Inside ibmasm_init_remote_input_dev, mouse_dev and keybd_dev are<br /> allocated by input_allocate_device(), and assigned to<br /> sp-&gt;remote.mouse_dev and sp-&gt;remote.keybd_dev respectively.<br /> <br /> In the err_free_devices error branch of ibmasm_init_one,<br /> mouse_dev and keybd_dev are freed by input_free_device(), and return<br /> error. Then the execution runs into error_send_message error branch<br /> of ibmasm_init_one, where ibmasm_free_remote_input_dev(sp) is called<br /> to unregister the freed sp-&gt;remote.mouse_dev and sp-&gt;remote.keybd_dev.<br /> <br /> My patch add a "error_init_remote" label to handle the error of<br /> ibmasm_init_remote_input_dev(), to avoid the uaf bugs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances<br /> <br /> As syzbot reported, there is an use-after-free issue during f2fs recovery:<br /> <br /> Use-after-free write at 0xffff88823bc16040 (in kfence-#10):<br /> kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486<br /> f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869<br /> f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945<br /> mount_bdev+0x26c/0x3a0 fs/super.c:1367<br /> legacy_get_tree+0xea/0x180 fs/fs_context.c:592<br /> vfs_get_tree+0x86/0x270 fs/super.c:1497<br /> do_new_mount fs/namespace.c:2905 [inline]<br /> path_mount+0x196f/0x2be0 fs/namespace.c:3235<br /> do_mount fs/namespace.c:3248 [inline]<br /> __do_sys_mount fs/namespace.c:3456 [inline]<br /> __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433<br /> do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is multi f2fs filesystem instances can race on accessing<br /> global fsync_entry_slab pointer, result in use-after-free issue of slab<br /> cache, fixes to init/destroy this slab cache only once during module<br /> init/destroy procedure to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smackfs: restrict bytes count in smk_set_cipso()<br /> <br /> Oops, I failed to update subject line.<br /> <br /> From 07571157c91b98ce1a4aa70967531e64b78e8346 Mon Sep 17 00:00:00 2001<br /> Date: Mon, 12 Apr 2021 22:25:06 +0900<br /> Subject: [PATCH] smackfs: restrict bytes count in smk_set_cipso()<br /> <br /> Commit 7ef4c19d245f3dc2 ("smackfs: restrict bytes count in smackfs write<br /> functions") missed that count &gt; SMK_CIPSOMAX check applies to only<br /> format == SMK_FIXED24_FMT case.