Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/habanalabs: fix mem leak in capture user mappings<br /> <br /> This commit fixes a memory leak caused when clearing the user_mappings<br /> info when a new context is opened immediately after user_mapping is<br /> captured and a hard reset is performed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix race issue between cpu buffer write and swap<br /> <br /> Warning happened in rb_end_commit() at code:<br /> if (RB_WARN_ON(cpu_buffer, !local_read(&amp;cpu_buffer-&gt;committing)))<br /> <br /> WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142<br /> rb_commit+0x402/0x4a0<br /> Call Trace:<br /> ring_buffer_unlock_commit+0x42/0x250<br /> trace_buffer_unlock_commit_regs+0x3b/0x250<br /> trace_event_buffer_commit+0xe5/0x440<br /> trace_event_buffer_reserve+0x11c/0x150<br /> trace_event_raw_event_sched_switch+0x23c/0x2c0<br /> __traceiter_sched_switch+0x59/0x80<br /> __schedule+0x72b/0x1580<br /> schedule+0x92/0x120<br /> worker_thread+0xa0/0x6f0<br /> <br /> It is because the race between writing event into cpu buffer and swapping<br /> cpu buffer through file per_cpu/cpu0/snapshot:<br /> <br /> Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1<br /> -------- --------<br /> tracing_snapshot_write()<br /> [...]<br /> <br /> ring_buffer_lock_reserve()<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 1. Suppose find &amp;#39;cpu_buffer_a&amp;#39;;<br /> [...]<br /> rb_reserve_next_event()<br /> [...]<br /> <br /> ring_buffer_swap_cpu()<br /> if (local_read(&amp;cpu_buffer_a-&gt;committing))<br /> goto out_dec;<br /> if (local_read(&amp;cpu_buffer_b-&gt;committing))<br /> goto out_dec;<br /> buffer_a-&gt;buffers[cpu] = cpu_buffer_b;<br /> buffer_b-&gt;buffers[cpu] = cpu_buffer_a;<br /> // 2. cpu_buffer has swapped here.<br /> <br /> rb_start_commit(cpu_buffer);<br /> if (unlikely(READ_ONCE(cpu_buffer-&gt;buffer)<br /> != buffer)) { // 3. This check passed due to &amp;#39;cpu_buffer-&gt;buffer&amp;#39;<br /> [...] // has not changed here.<br /> return NULL;<br /> }<br /> cpu_buffer_b-&gt;buffer = buffer_a;<br /> cpu_buffer_a-&gt;buffer = buffer_b;<br /> [...]<br /> <br /> // 4. Reserve event from &amp;#39;cpu_buffer_a&amp;#39;.<br /> <br /> ring_buffer_unlock_commit()<br /> [...]<br /> cpu_buffer = buffer-&gt;buffers[cpu]; // 5. Now find &amp;#39;cpu_buffer_b&amp;#39; !!!<br /> rb_commit(cpu_buffer)<br /> rb_end_commit() // 6. WARN for the wrong &amp;#39;committing&amp;#39; state !!!<br /> <br /> Based on above analysis, we can easily reproduce by following testcase:<br /> ``` bash<br /> #!/bin/bash<br /> <br /> dmesg -n 7<br /> sysctl -w kernel.panic_on_warn=1<br /> TR=/sys/kernel/tracing<br /> echo 7 &gt; ${TR}/buffer_size_kb<br /> echo "sched:sched_switch" &gt; ${TR}/set_event<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> while [ true ]; do<br /> echo 1 &gt; ${TR}/per_cpu/cpu0/snapshot<br /> done &amp;<br /> ```<br /> <br /> To fix it, IIUC, we can use smp_call_function_single() to do the swap on<br /> the target cpu where the buffer is located, so that above race would be<br /> avoided.

Use of Hard-coded Credentials vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5 and newer versions

Use of a One-Way Hash with a Predictable Salt vulnerability in ABB FLXEON.This issue affects FLXEON: through 9.3.5. and newer versions

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic at<br /> once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSv4.2: Rework scratch handling for READ_PLUS (again)<br /> <br /> I found that the read code might send multiple requests using the same<br /> nfs_pgio_header, but nfs4_proc_read_setup() is only called once. This is<br /> how we ended up occasionally double-freeing the scratch buffer, but also<br /> means we set a NULL pointer but non-zero length to the xdr scratch<br /> buffer. This results in an oops the first time decoding needs to copy<br /> something to scratch, which frequently happens when decoding READ_PLUS<br /> hole segments.<br /> <br /> I fix this by moving scratch handling into the pageio read code. I<br /> provide a function to allocate scratch space for decoding read replies,<br /> and free the scratch buffer when the nfs_pgio_header is freed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: mm: Add p?d_leaf() definitions<br /> <br /> When I do LTP test, LTP test case ksm06 caused panic at<br /> break_ksm_pmd_entry<br /> -&gt; pmd_leaf (Huge page table but False)<br /> -&gt; pte_present (panic)<br /> <br /> The reason is pmd_leaf() is not defined, So like commit 501b81046701<br /> ("mips: mm: add p?d_leaf() definitions") add p?d_leaf() definition for<br /> LoongArch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc: don&amp;#39;t assume child devices are all fsl-mc devices<br /> <br /> Changes in VFIO caused a pseudo-device to be created as child of<br /> fsl-mc devices causing a crash [1] when trying to bind a fsl-mc<br /> device to VFIO. Fix this by checking the device type when enumerating<br /> fsl-mc child devices.<br /> <br /> [1]<br /> Modules linked in:<br /> Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP<br /> CPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2<br /> Hardware name: NXP Layerscape LX2160ARDB (DT)<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mc_send_command+0x24/0x1f0<br /> lr : dprc_get_obj_region+0xfc/0x1c0<br /> sp : ffff80000a88b900<br /> x29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2<br /> x26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000<br /> x20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001<br /> x17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff<br /> x14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386<br /> x11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012<br /> x8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8<br /> x2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80<br /> Call trace:<br /> mc_send_command+0x24/0x1f0<br /> dprc_get_obj_region+0xfc/0x1c0<br /> fsl_mc_device_add+0x340/0x590<br /> fsl_mc_obj_device_add+0xd0/0xf8<br /> dprc_scan_objects+0x1c4/0x340<br /> dprc_scan_container+0x38/0x60<br /> vfio_fsl_mc_probe+0x9c/0xf8<br /> fsl_mc_driver_probe+0x24/0x70<br /> really_probe+0xbc/0x2a8<br /> __driver_probe_device+0x78/0xe0<br /> device_driver_attach+0x30/0x68<br /> bind_store+0xa8/0x130<br /> drv_attr_store+0x24/0x38<br /> sysfs_kf_write+0x44/0x60<br /> kernfs_fop_write_iter+0x128/0x1b8<br /> vfs_write+0x334/0x448<br /> ksys_write+0x68/0xf0<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x44/0x108<br /> el0_svc_common.constprop.1+0x94/0xf8<br /> do_el0_svc+0x38/0xb0<br /> el0_svc+0x20/0x50<br /> el0t_64_sync_handler+0x98/0xc0<br /> el0t_64_sync+0x174/0x178<br /> Code: aa0103f4 a9025bf5 d5384100 b9400801 (79401260)<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix use-after-free in pci_bus_release_domain_nr()<br /> <br /> Commit c14f7ccc9f5d ("PCI: Assign PCI domain IDs by ida_alloc()")<br /> introduced a use-after-free bug in the bus removal cleanup. The issue was<br /> found with kfence:<br /> <br /> [ 19.293351] BUG: KFENCE: use-after-free read in pci_bus_release_domain_nr+0x10/0x70<br /> <br /> [ 19.302817] Use-after-free read at 0x000000007f3b80eb (in kfence-#115):<br /> [ 19.309677] pci_bus_release_domain_nr+0x10/0x70<br /> [ 19.309691] dw_pcie_host_deinit+0x28/0x78<br /> [ 19.309702] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]<br /> [ 19.309734] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]<br /> [ 19.309752] platform_probe+0x90/0xd8<br /> ...<br /> <br /> [ 19.311457] kfence-#115: 0x00000000063a155a-0x00000000ba698da8, size=1072, cache=kmalloc-2k<br /> <br /> [ 19.311469] allocated by task 96 on cpu 10 at 19.279323s:<br /> [ 19.311562] __kmem_cache_alloc_node+0x260/0x278<br /> [ 19.311571] kmalloc_trace+0x24/0x30<br /> [ 19.311580] pci_alloc_bus+0x24/0xa0<br /> [ 19.311590] pci_register_host_bridge+0x48/0x4b8<br /> [ 19.311601] pci_scan_root_bus_bridge+0xc0/0xe8<br /> [ 19.311613] pci_host_probe+0x18/0xc0<br /> [ 19.311623] dw_pcie_host_init+0x2c0/0x568<br /> [ 19.311630] tegra_pcie_dw_probe+0x610/0xb28 [pcie_tegra194]<br /> [ 19.311647] platform_probe+0x90/0xd8<br /> ...<br /> <br /> [ 19.311782] freed by task 96 on cpu 10 at 19.285833s:<br /> [ 19.311799] release_pcibus_dev+0x30/0x40<br /> [ 19.311808] device_release+0x30/0x90<br /> [ 19.311814] kobject_put+0xa8/0x120<br /> [ 19.311832] device_unregister+0x20/0x30<br /> [ 19.311839] pci_remove_bus+0x78/0x88<br /> [ 19.311850] pci_remove_root_bus+0x5c/0x98<br /> [ 19.311860] dw_pcie_host_deinit+0x28/0x78<br /> [ 19.311866] tegra_pcie_deinit_controller+0x1c/0x38 [pcie_tegra194]<br /> [ 19.311883] tegra_pcie_dw_probe+0x648/0xb28 [pcie_tegra194]<br /> [ 19.311900] platform_probe+0x90/0xd8<br /> ...<br /> <br /> [ 19.313579] CPU: 10 PID: 96 Comm: kworker/u24:2 Not tainted 6.2.0 #4<br /> [ 19.320171] Hardware name: /, BIOS 1.0-d7fb19b 08/10/2022<br /> [ 19.325852] Workqueue: events_unbound deferred_probe_work_func<br /> <br /> The stack trace is a bit misleading as dw_pcie_host_deinit() doesn&amp;#39;t<br /> directly call pci_bus_release_domain_nr(). The issue turns out to be in<br /> pci_remove_root_bus() which first calls pci_remove_bus() which frees the<br /> struct pci_bus when its struct device is released. Then<br /> pci_bus_release_domain_nr() is called and accesses the freed struct<br /> pci_bus. Reordering these fixes the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9063: better fix null deref with partial DT<br /> <br /> Two versions of the original patch were sent but V1 was merged instead<br /> of V2 due to a mistake.<br /> <br /> So update to V2.<br /> <br /> The advantage of V2 is that it completely avoids dereferencing the pointer,<br /> even just to take the address, which may fix problems with some compilers.<br /> Both versions work on my gcc 9.4 but use the safer one.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6mr: Fix skb_under_panic in ip6mr_cache_report()<br /> <br /> skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4<br /> head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/skbuff.c:192!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:skb_panic+0x152/0x1d0<br /> Call Trace:<br /> <br /> skb_push+0xc4/0xe0<br /> ip6mr_cache_report+0xd69/0x19b0<br /> reg_vif_xmit+0x406/0x690<br /> dev_hard_start_xmit+0x17e/0x6e0<br /> __dev_queue_xmit+0x2d6a/0x3d20<br /> vlan_dev_hard_start_xmit+0x3ab/0x5c0<br /> dev_hard_start_xmit+0x17e/0x6e0<br /> __dev_queue_xmit+0x2d6a/0x3d20<br /> neigh_connected_output+0x3ed/0x570<br /> ip6_finish_output2+0x5b5/0x1950<br /> ip6_finish_output+0x693/0x11c0<br /> ip6_output+0x24b/0x880<br /> NF_HOOK.constprop.0+0xfd/0x530<br /> ndisc_send_skb+0x9db/0x1400<br /> ndisc_send_rs+0x12a/0x6c0<br /> addrconf_dad_completed+0x3c9/0xea0<br /> addrconf_dad_work+0x849/0x1420<br /> process_one_work+0xa22/0x16e0<br /> worker_thread+0x679/0x10c0<br /> ret_from_fork+0x28/0x60<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().<br /> reg_vif_xmit()<br /> ip6mr_cache_report()<br /> skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4<br /> And skb_push declared as:<br /> void *skb_push(struct sk_buff *skb, unsigned int len);<br /> skb-&gt;data -= len;<br /> //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850<br /> skb-&gt;data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: be a bit more careful in checking for NULL bdev while polling<br /> <br /> Wei reports a crash with an application using polled IO:<br /> <br /> PGD 14265e067 P4D 14265e067 PUD 47ec50067 PMD 0<br /> Oops: 0000 [#1] SMP<br /> CPU: 0 PID: 21915 Comm: iocore_0 Kdump: loaded Tainted: G S 5.12.0-0_fbk12_clang_7346_g1bb6f2e7058f #1<br /> Hardware name: Wiwynn Delta Lake MP T8/Delta Lake-Class2, BIOS Y3DLM08 04/10/2022<br /> RIP: 0010:bio_poll+0x25/0x200<br /> Code: 0f 1f 44 00 00 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 44 24 20 48 8b 47 08 8b 80 70 02 00 00 4c 8b 70 50 8b 6f 34 31 db 83 fd ff 75 25 65<br /> RSP: 0018:ffffc90005fafdf8 EFLAGS: 00010292<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: 74b43cd65dd66600<br /> RDX: 0000000000000003 RSI: ffffc90005fafe78 RDI: ffff8884b614e140<br /> RBP: ffff88849964df78 R08: 0000000000000000 R09: 0000000000000008<br /> R10: 0000000000000000 R11: 0000000000000000 R12: ffff88849964df00<br /> R13: ffffc90005fafe78 R14: ffff888137d3c378 R15: 0000000000000001<br /> FS: 00007fd195000640(0000) GS:ffff88903f400000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000270 CR3: 0000000466121001 CR4: 00000000007706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> iocb_bio_iopoll+0x1d/0x30<br /> io_do_iopoll+0xac/0x250<br /> __se_sys_io_uring_enter+0x3c5/0x5a0<br /> ? __x64_sys_write+0x89/0xd0<br /> do_syscall_64+0x2d/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x94f225d<br /> Code: 24 cc 00 00 00 41 8b 84 24 d0 00 00 00 c1 e0 04 83 e0 10 41 09 c2 8b 33 8b 53 04 4c 8b 43 18 4c 63 4b 0c b8 aa 01 00 00 0f 05 c0 0f 88 85 00 00 00 29 03 45 84 f6 0f 84 88 00 00 00 41 f6 c7<br /> RSP: 002b:00007fd194ffcd88 EFLAGS: 00000202 ORIG_RAX: 00000000000001aa<br /> RAX: ffffffffffffffda RBX: 00007fd194ffcdc0 RCX: 00000000094f225d<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000007<br /> RBP: 00007fd194ffcdb0 R08: 0000000000000000 R09: 0000000000000008<br /> R10: 0000000000000001 R11: 0000000000000202 R12: 00007fd269d68030<br /> R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000000<br /> <br /> which is due to bio-&gt;bi_bdev being NULL. This can happen if we have two<br /> tasks doing polled IO, and task B ends up completing IO from task A if<br /> they are sharing a poll queue. If task B completes the IO and puts the<br /> bio into our cache, then it can allocate that bio again before task A<br /> is done polling for it. As that would necessitate a preempt between the<br /> two tasks, it&amp;#39;s enough to just be a bit more careful in checking for<br /> whether or not bio-&gt;bi_bdev is NULL.