Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/mm: Fix lockup on kernel exec fault<br /> <br /> The powerpc kernel is not prepared to handle exec faults from kernel.<br /> Especially, the function is_exec_fault() will return &amp;#39;false&amp;#39; when an<br /> exec fault is taken by kernel, because the check is based on reading<br /> current-&gt;thread.regs-&gt;trap which contains the trap from user.<br /> <br /> For instance, when provoking a LKDTM EXEC_USERSPACE test,<br /> current-&gt;thread.regs-&gt;trap is set to SYSCALL trap (0xc00), and<br /> the fault taken by the kernel is not seen as an exec fault by<br /> set_access_flags_filter().<br /> <br /> Commit d7df2443cd5f ("powerpc/mm: Fix spurious segfaults on radix<br /> with autonuma") made it clear and handled it properly. But later on<br /> commit d3ca587404b3 ("powerpc/mm: Fix reporting of kernel execute<br /> faults") removed that handling, introducing test based on error_code.<br /> And here is the problem, because on the 603 all upper bits of SRR1<br /> get cleared when the TLB instruction miss handler bails out to ISI.<br /> <br /> Until commit cbd7e6ca0210 ("powerpc/fault: Avoid heavy<br /> search_exception_tables() verification"), an exec fault from kernel<br /> at a userspace address was indirectly caught by the lack of entry for<br /> that address in the exception tables. But after that commit the<br /> kernel mainly relies on KUAP or on core mm handling to catch wrong<br /> user accesses. Here the access is not wrong, so mm handles it.<br /> It is a minor fault because PAGE_EXEC is not set,<br /> set_access_flags_filter() should set PAGE_EXEC and voila.<br /> But as is_exec_fault() returns false as explained in the beginning,<br /> set_access_flags_filter() bails out without setting PAGE_EXEC flag,<br /> which leads to a forever minor exec fault.<br /> <br /> As the kernel is not prepared to handle such exec faults, the thing to<br /> do is to fire in bad_kernel_fault() for any exec fault taken by the<br /> kernel, as it was prior to commit d3ca587404b3.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix races between xattr_{set|get} and listxattr operations<br /> <br /> UBIFS may occur some problems with concurrent xattr_{set|get} and<br /> listxattr operations, such as assertion failure, memory corruption,<br /> stale xattr value[1].<br /> <br /> Fix it by importing a new rw-lock in @ubifs_inode to serilize write<br /> operations on xattr, concurrent read operations are still effective,<br /> just like ext4.<br /> <br /> [1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Fix NULL pointer dereference in udf_symlink function<br /> <br /> In function udf_symlink, epos.bh is assigned with the value returned<br /> by udf_tgetblk. The function udf_tgetblk is defined in udf/misc.c<br /> and returns the value of sb_getblk function that could be NULL.<br /> Then, epos.bh is used without any check, causing a possible<br /> NULL pointer dereference when sb_getblk fails.<br /> <br /> This fix adds a check to validate the value of epos.bh.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Avoid data corruptions<br /> <br /> Wait for all dependencies of a job to complete before<br /> killing it to avoid data corruptions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: nicstar: Fix possible use-after-free in nicstar_cleanup()<br /> <br /> This module&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mISDN: fix possible use-after-free in HFC_cleanup()<br /> <br /> This module&amp;#39;s remove path calls del_timer(). However, that function<br /> does not wait until the timer handler finishes. This means that the<br /> timer handler may still be running after the driver&amp;#39;s remove function<br /> has finished, which would result in a use-after-free.<br /> <br /> Fix by calling del_timer_sync(), which makes sure the timer handler<br /> has finished, and unable to re-schedule itself.

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.