Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFS: Fix a potential data corruption<br /> <br /> We must ensure that the subrequests are joined back into the head before<br /> we can retransmit a request. If the head was not on the commit lists,<br /> because the server wrote it synchronously, we still need to add it back<br /> to the retransmission list.<br /> Add a call that mirrors the effect of nfs_cancel_remove_inode() for<br /> O_DIRECT.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9317/1: kexec: Make smp stop calls asynchronous<br /> <br /> If a panic is triggered by a hrtimer interrupt all online cpus will be<br /> notified and set offline. But as highlighted by commit 19dbdcb8039c<br /> ("smp: Warn on function calls from softirq context") this call should<br /> not be made synchronous with disabled interrupts:<br /> <br /> softdog: Initiating panic<br /> Kernel panic - not syncing: Software Watchdog Timer expired<br /> WARNING: CPU: 1 PID: 0 at kernel/smp.c:753 smp_call_function_many_cond<br /> unwind_backtrace:<br /> show_stack<br /> dump_stack_lvl<br /> __warn<br /> warn_slowpath_fmt<br /> smp_call_function_many_cond<br /> smp_call_function<br /> crash_smp_send_stop.part.0<br /> machine_crash_shutdown<br /> __crash_kexec<br /> panic<br /> softdog_fire<br /> __hrtimer_run_queues<br /> hrtimer_interrupt<br /> <br /> Make the smp call for machine_crash_nonpanic_core() asynchronous.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: sme: Use STR P to clear FFR context field in streaming SVE mode<br /> <br /> The FFR is a predicate register which can vary between 16 and 256 bits<br /> in size depending upon the configured vector length. When saving the<br /> SVE state in streaming SVE mode, the FFR register is inaccessible and<br /> so commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simply<br /> clears the FFR field of the in-memory context structure. Unfortunately,<br /> it achieves this using an unconditional 8-byte store and so if the SME<br /> vector length is anything other than 64 bytes in size we will either<br /> fail to clear the entire field or, worse, we will corrupt memory<br /> immediately following the structure. This has led to intermittent kfence<br /> splats in CI [1] and can trigger kmalloc Redzone corruption messages<br /> when running the &amp;#39;fp-stress&amp;#39; kselftest:<br /> <br /> | =============================================================================<br /> | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten<br /> | -----------------------------------------------------------------------------<br /> |<br /> | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc<br /> | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531<br /> | __kmalloc+0x8c/0xcc<br /> | do_sme_acc+0x9c/0x220<br /> | ...<br /> <br /> Replace the 8-byte store with a store of a predicate register which has<br /> been zero-initialised with PFALSE, ensuring that the entire field is<br /> cleared in memory.<br /> <br /> [1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Detect system inodes linked into directory hierarchy<br /> <br /> When UDF filesystem is corrupted, hidden system inodes can be linked<br /> into directory hierarchy which is an avenue for further serious<br /> corruption of the filesystem and kernel confusion as noticed by syzbot<br /> fuzzed images. Refuse to access system inodes linked into directory<br /> hierarchy and vice versa.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()<br /> <br /> There is a memory leak reported by kmemleak:<br /> <br /> unreferenced object 0xffffc900003f0000 (size 12288):<br /> comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s)<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 /> [] __vmalloc_node_range+0xe56/0x1110<br /> [] __vmalloc_node+0xbd/0x150<br /> [] vmalloc+0x25/0x30<br /> [] qla2x00_create_host+0x7a0/0xe30 [qla2xxx]<br /> [] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx]<br /> [] local_pci_probe+0xeb/0x1a0<br /> <br /> The root cause is traced to an error-handling path in qla2x00_probe_one()<br /> when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" is<br /> used to record the port information and it is allocated in<br /> qla2x00_create_host(). However, it is not released in the error handling<br /> path "probe_failed".<br /> <br /> Fix this by freeing the memory of "scan.l" when an error occurs in the<br /> adapter initialization process.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvdimm: Fix memleak of pmu attr_groups in unregister_nvdimm_pmu()<br /> <br /> Memory pointed by &amp;#39;nd_pmu-&gt;pmu.attr_groups&amp;#39; is allocated in function<br /> &amp;#39;register_nvdimm_pmu&amp;#39; and is lost after &amp;#39;kfree(nd_pmu)&amp;#39; call in function<br /> &amp;#39;unregister_nvdimm_pmu&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix refcount underflow in error path<br /> <br /> Fix a refcount underflow problem reported by syzbot that can happen<br /> when a system is running out of memory. If xp_alloc_tx_descs() fails,<br /> and it can only fail due to not having enough memory, then the error<br /> path is triggered. In this error path, the refcount of the pool is<br /> decremented as it has incremented before. However, the reference to<br /> the pool in the socket was not nulled. This means that when the socket<br /> is closed later, the socket teardown logic will think that there is a<br /> pool attached to the socket and try to decrease the refcount again,<br /> leading to a refcount underflow.<br /> <br /> I chose this fix as it involved adding just a single line. Another<br /> option would have been to move xp_get_pool() and the assignment of<br /> xs-&gt;pool to after the if-statement and using xs_umem-&gt;pool instead of<br /> xs-&gt;pool in the whole if-statement resulting in somewhat simpler code,<br /> but this would have led to much more churn in the code base perhaps<br /> making it harder to backport.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: move memblock_allow_resize() after linear mapping is ready<br /> <br /> The initial memblock metadata is accessed from kernel image mapping. The<br /> regions arrays need to "reallocated" from memblock and accessed through<br /> linear mapping to cover more memblock regions. So the resizing should<br /> not be allowed until linear mapping is ready. Note that there are<br /> memblock allocations when building linear mapping.<br /> <br /> This patch is similar to 24cc61d8cb5a ("arm64: memblock: don&amp;#39;t permit<br /> memblock resizing until linear mapping is up").<br /> <br /> In following log, many memblock regions are reserved before<br /> create_linear_mapping_page_table(). And then it triggered reallocation<br /> of memblock.reserved.regions and memcpy the old array in kernel image<br /> mapping to the new array in linear mapping which caused a page fault.<br /> <br /> [ 0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6<br /> [ 0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000<br /> [ 0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae<br /> [ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c<br /> [ 0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128<br /> [ 0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff]<br /> [ 0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000<br /> [ 0.000000] Oops [#1]<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66<br /> [ 0.000000] Hardware name: riscv-virtio,qemu (DT)<br /> [ 0.000000] epc : __memcpy+0x60/0xf8<br /> [ 0.000000] ra : memblock_double_array+0x192/0x248<br /> [ 0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0<br /> [ 0.000000] gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000<br /> [ 0.000000] t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60<br /> [ 0.000000] s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8<br /> [ 0.000000] a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000<br /> [ 0.000000] a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000<br /> [ 0.000000] s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00<br /> [ 0.000000] s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000<br /> [ 0.000000] s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000<br /> [ 0.000000] s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000<br /> [ 0.000000] t5 : 000000008f003000 t6 : ff600000ffffd000<br /> [ 0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f<br /> [ 0.000000] [

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: max9286: Fix memleak in max9286_v4l2_register()<br /> <br /> There is a kmemleak when testing the media/i2c/max9286.c with bpf mock<br /> device:<br /> <br /> kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> <br /> unreferenced object 0xffff88810defc400 (size 256):<br /> comm "python3", pid 278, jiffies 4294737563 (age 31.978s)<br /> hex dump (first 32 bytes):<br /> 28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff (.........".....<br /> 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................<br /> backtrace:<br /> [] __kmalloc_node+0x44/0x1b0<br /> [] kvmalloc_node+0x34/0x180<br /> [] v4l2_ctrl_new+0x325/0x10f0 [videodev]<br /> [] v4l2_ctrl_new_std+0x16f/0x210 [videodev]<br /> [] max9286_probe+0x76e/0xbff [max9286]<br /> [] i2c_device_probe+0x28d/0x680<br /> [] really_probe+0x17c/0x3f0<br /> [] __driver_probe_device+0xe3/0x170<br /> [] driver_probe_device+0x49/0x120<br /> [] __device_attach_driver+0xf7/0x150<br /> [] bus_for_each_drv+0x114/0x180<br /> [] __device_attach+0x1e5/0x2d0<br /> [] bus_probe_device+0x126/0x140<br /> [] device_add+0x810/0x1130<br /> [] i2c_new_client_device+0x359/0x4f0<br /> [] of_i2c_register_device+0xf1/0x110<br /> <br /> max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won&amp;#39;t free the<br /> created v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, which<br /> causes the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/crypto: use vector instructions only if available for ChaCha20<br /> <br /> Commit 349d03ffd5f6 ("crypto: s390 - add crypto library interface for<br /> ChaCha20") added a library interface to the s390 specific ChaCha20<br /> implementation. However no check was added to verify if the required<br /> facilities are installed before branching into the assembler code.<br /> <br /> If compiled into the kernel, this will lead to the following crash,<br /> if vector instructions are not available:<br /> <br /> data exception: 0007 ilc:3 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7+ #11<br /> Hardware name: IBM 3931 A01 704 (KVM/Linux)<br /> Krnl PSW : 0704e00180000000 000000001857277a (chacha20_vx+0x32/0x818)<br /> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3<br /> Krnl GPRS: 0000037f0000000a ffffffffffffff60 000000008184b000 0000000019f5c8e6<br /> 0000000000000109 0000037fffb13c58 0000037fffb13c78 0000000019bb1780<br /> 0000037fffb13c58 0000000019f5c8e6 000000008184b000 0000000000000109<br /> 00000000802d8000 0000000000000109 0000000018571ebc 0000037fffb13718<br /> Krnl Code: 000000001857276a: c07000b1f80b larl %r7,0000000019bb1780<br /> 0000000018572770: a708000a lhi %r0,10<br /> #0000000018572774: e78950000c36 vlm %v24,%v25,0(%r5),0<br /> &gt;000000001857277a: e7a060000806 vl %v26,0(%r6),0<br /> 0000000018572780: e7bf70004c36 vlm %v27,%v31,0(%r7),4<br /> 0000000018572786: e70b00000456 vlr %v0,%v27<br /> 000000001857278c: e71800000456 vlr %v1,%v24<br /> 0000000018572792: e74b00000456 vlr %v4,%v27<br /> Call Trace:<br /> [] chacha20_vx+0x32/0x818<br /> Last Breaking-Event-Address:<br /> [] chacha20_crypt_s390.constprop.0+0x6e/0xd8<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b<br /> <br /> Fix this by adding a missing MACHINE_HAS_VX check.<br /> <br /> [agordeev@linux.ibm.com: remove duplicates in commit message]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: amd_sfh: Fix for shift-out-of-bounds<br /> <br /> Shift operation of &amp;#39;exp&amp;#39; and &amp;#39;shift&amp;#39; variables exceeds the maximum number<br /> of shift values in the u32 range leading to UBSAN shift-out-of-bounds.<br /> <br /> ...<br /> [ 6.120512] UBSAN: shift-out-of-bounds in drivers/hid/amd-sfh-hid/sfh1_1/amd_sfh_desc.c:149:50<br /> [ 6.120598] shift exponent 104 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> [ 6.120659] CPU: 4 PID: 96 Comm: kworker/4:1 Not tainted 6.4.0amd_1-next-20230519-dirty #10<br /> [ 6.120665] Hardware name: AMD Birman-PHX/Birman-PHX, BIOS SFH_with_HPD_SEN.FD 04/05/2023<br /> [ 6.120667] Workqueue: events amd_sfh_work_buffer [amd_sfh]<br /> [ 6.120687] Call Trace:<br /> [ 6.120690] <br /> [ 6.120694] dump_stack_lvl+0x48/0x70<br /> [ 6.120704] dump_stack+0x10/0x20<br /> [ 6.120707] ubsan_epilogue+0x9/0x40<br /> [ 6.120716] __ubsan_handle_shift_out_of_bounds+0x10f/0x170<br /> [ 6.120720] ? psi_group_change+0x25f/0x4b0<br /> [ 6.120729] float_to_int.cold+0x18/0xba [amd_sfh]<br /> [ 6.120739] get_input_rep+0x57/0x340 [amd_sfh]<br /> [ 6.120748] ? __schedule+0xba7/0x1b60<br /> [ 6.120756] ? __pfx_get_input_rep+0x10/0x10 [amd_sfh]<br /> [ 6.120764] amd_sfh_work_buffer+0x91/0x180 [amd_sfh]<br /> [ 6.120772] process_one_work+0x229/0x430<br /> [ 6.120780] worker_thread+0x4a/0x3c0<br /> [ 6.120784] ? __pfx_worker_thread+0x10/0x10<br /> [ 6.120788] kthread+0xf7/0x130<br /> [ 6.120792] ? __pfx_kthread+0x10/0x10<br /> [ 6.120795] ret_from_fork+0x29/0x50<br /> [ 6.120804] <br /> ...<br /> <br /> Fix this by adding the condition to validate shift ranges.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()<br /> <br /> Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc()<br /> which can automatically release the related memory when the device<br /> or driver is removed or unloaded to avoid potential memory leak.<br /> <br /> In this case, iounmap(anatop_base) in line 427,433 are removed<br /> as manual release is not required.<br /> <br /> Besides, referring to clk-imx8mq.c, check the return code of<br /> of_clk_add_hw_provider, if it returns negtive, print error info<br /> and unregister hws, which makes the program more robust.