Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1<br /> <br /> The type of size is unsigned int, if size is 0x40000000, there will<br /> be an integer overflow, size will be zero after size *= sizeof(uint32_t),<br /> will cause uninitialized memory to be referenced later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objects<br /> <br /> If a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`<br /> objects while evaluating the AMD LPS0 _DSM, there will be a memory<br /> leak. Explicitly guard against this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Handle race between rb_move_tail and rb_check_pages<br /> <br /> It seems a data race between ring_buffer writing and integrity check.<br /> That is, RB_FLAG of head_page is been updating, while at same time<br /> RB_FLAG was cleared when doing integrity check rb_check_pages():<br /> <br /> rb_check_pages() rb_handle_head_page():<br /> -------- --------<br /> rb_head_page_deactivate()<br /> rb_head_page_set_normal()<br /> rb_head_page_activate()<br /> <br /> We do intergrity test of the list to check if the list is corrupted and<br /> it is still worth doing it. So, let&amp;#39;s refactor rb_check_pages() such that<br /> we no longer clear and set flag during the list sanity checking.<br /> <br /> [1] and [2] are the test to reproduce and the crash report respectively.<br /> <br /> 1:<br /> ``` read_trace.sh<br /> while true;<br /> do<br /> # the "trace" file is closed after read<br /> head -1 /sys/kernel/tracing/trace &gt; /dev/null<br /> done<br /> ```<br /> ``` repro.sh<br /> sysctl -w kernel.panic_on_warn=1<br /> # function tracer will writing enough data into ring_buffer<br /> echo function &gt; /sys/kernel/tracing/current_tracer<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ./read_trace.sh &amp;<br /> ```<br /> <br /> 2:<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653<br /> rb_move_tail+0x450/0x470<br /> Modules linked in:<br /> CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G W 6.2.0-rc6+<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:rb_move_tail+0x450/0x470<br /> Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 24<br /> 83 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 0b 83<br /> f8 02 0f 84 ce fb ff ff e9 db<br /> RSP: 0018:ffffb5564089bd00 EFLAGS: 00000203<br /> RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18<br /> RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400<br /> RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2<br /> R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000<br /> R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108<br /> FS: 0000000000000000(0000) GS:ffff9db3bdcc0000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0<br /> Call Trace:<br /> <br /> ring_buffer_lock_reserve+0x136/0x360<br /> ? __do_softirq+0x287/0x2df<br /> ? __pfx_rcu_softirq_qs+0x10/0x10<br /> trace_function+0x21/0x110<br /> ? __pfx_rcu_softirq_qs+0x10/0x10<br /> ? __do_softirq+0x287/0x2df<br /> function_trace_call+0xf6/0x120<br /> 0xffffffffc038f097<br /> ? rcu_softirq_qs+0x5/0x140<br /> rcu_softirq_qs+0x5/0x140<br /> __do_softirq+0x287/0x2df<br /> run_ksoftirqd+0x2a/0x30<br /> smpboot_thread_fn+0x188/0x220<br /> ? __pfx_smpboot_thread_fn+0x10/0x10<br /> kthread+0xe7/0x110<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> [ crash report and test reproducer credit goes to Zheng Yejian]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: fix error code of return in mt7921_acpi_read<br /> <br /> Kernel NULL pointer dereference when ACPI SAR table isn&amp;#39;t implemented well.<br /> Fix the error code of return to mark the ACPI SAR table as invalid.<br /> <br /> [ 5.077128] mt7921e 0000:06:00.0: sar cnt = 0<br /> [ 5.077381] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000004<br /> [ 5.077630] #PF: supervisor read access in kernel mode<br /> [ 5.077883] #PF: error_code(0x0000) - not-present page<br /> [ 5.078138] PGD 0 P4D 0<br /> [ 5.078398] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 5.079202] RIP: 0010:mt7921_init_acpi_sar+0x106/0x220<br /> [mt7921_common]<br /> ...<br /> [ 5.080786] Call Trace:<br /> [ 5.080786] <br /> [ 5.080786] mt7921_register_device+0x37d/0x490 [mt7921_common]<br /> [ 5.080786] mt7921_pci_probe.part.0+0x2ee/0x310 [mt7921e]<br /> [ 5.080786] mt7921_pci_probe+0x52/0x70 [mt7921e]<br /> [ 5.080786] local_pci_probe+0x47/0x90<br /> [ 5.080786] pci_call_probe+0x55/0x190<br /> [ 5.080786] pci_device_probe+0x84/0x120

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

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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.