Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]<br /> <br /> With default config, the value of NR_CPUS is 64. When HW platform has<br /> more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC<br /> is the maximum cpu number in MADT table (max physical number) which can<br /> exceed the supported maximum cpu number (NR_CPUS, max logical number),<br /> but kernel should not crash. Kernel should boot cpus with NR_CPUS, let<br /> the remainder cpus stay in BIOS.<br /> <br /> The potential crash reason is that the array acpi_core_pic[NR_CPUS] can<br /> be overflowed when parsing MADT table, and it is obvious that CORE_PIC<br /> should be corresponding to physical core rather than logical core, so it<br /> is better to define the array as acpi_core_pic[MAX_CORE_PIC].<br /> <br /> With the patch, system can boot up 64 vcpus with qemu parameter -smp 128,<br /> otherwise system will crash with the following message.<br /> <br /> [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec<br /> [ 0.000000] Oops[#1]:<br /> [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192<br /> [ 0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022<br /> [ 0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60<br /> [ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8<br /> [ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005<br /> [ 0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001<br /> [ 0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063<br /> [ 0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98<br /> [ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90<br /> [ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330<br /> [ 0.000000] ra: 90000000037a46ec platform_init+0x214/0x250<br /> [ 0.000000] ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94<br /> [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE)<br /> [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> [ 0.000000] ECFG: 00070800 (LIE=11 VS=7)<br /> [ 0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)<br /> [ 0.000000] BADV: 0000420000004259<br /> [ 0.000000] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____))<br /> [ 0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec<br /> [ 0.000000] 000000000a7fd000 0000000008290000 0000000000000000 0000000000000000<br /> [ 0.000000] 0000000000000000 0000000000000000 00000000019d8000 000000000f556b60<br /> [ 0.000000] 000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000<br /> [ 0.000000] 9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c<br /> [ 0.000000] 000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08<br /> [ 0.000000] 9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018<br /> [ 0.000000] 000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000<br /> [ 0.000000] 0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000<br /> [ 0.000000] 000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000<br /> [ 0.000000] ...<br /> [ 0.000000] Call Trace:<br /> [ 0.000000] [] efi_runtime_init+0x30/0x94<br /> [ 0.000000] [] platform_init+0x214/0x250<br /> [ 0.000000] [] setup_arch+0x124/0x45c<br /> [ 0.000000] [] start_kernel+0x90/0x670<br /> [ 0.000000] [] kernel_entry+0xd8/0xdc

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-fc: avoid deadlock on delete association path<br /> <br /> When deleting an association the shutdown path is deadlocking because we<br /> try to flush the nvmet_wq nested. Avoid this by deadlock by deferring<br /> the put work into its own work item.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: nvidia-shield: Add missing null pointer checks to LED initialization<br /> <br /> devm_kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.<br /> <br /> [jkosina@suse.com: tweak changelog a bit]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: edma: Add some null pointer checks to the edma_probe<br /> <br /> devm_kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: fixed integer types and null check locations<br /> <br /> [why]:<br /> issues fixed:<br /> - comparison with wider integer type in loop condition which can cause<br /> infinite loops<br /> - pointer dereference before null check

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arp: Prevent overflow in arp_req_get().<br /> <br /> syzkaller reported an overflown write in arp_req_get(). [0]<br /> <br /> When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour<br /> entry and copies neigh-&gt;ha to struct arpreq.arp_ha.sa_data.<br /> <br /> The arp_ha here is struct sockaddr, not struct sockaddr_storage, so<br /> the sa_data buffer is just 14 bytes.<br /> <br /> In the splat below, 2 bytes are overflown to the next int field,<br /> arp_flags. We initialise the field just after the memcpy(), so it&amp;#39;s<br /> not a problem.<br /> <br /> However, when dev-&gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),<br /> arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)<br /> in arp_ioctl() before calling arp_req_get().<br /> <br /> To avoid the overflow, let&amp;#39;s limit the max length of memcpy().<br /> <br /> Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible<br /> array in struct sockaddr") just silenced syzkaller.<br /> <br /> [0]:<br /> memcpy: detected field-spanning write (size 16) of single field "r-&gt;arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14)<br /> WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128<br /> Modules linked in:<br /> CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014<br /> RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128<br /> Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6<br /> RSP: 0018:ffffc900050b7998 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001<br /> RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000<br /> R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010<br /> FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261<br /> inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981<br /> sock_do_ioctl+0xdf/0x260 net/socket.c:1204<br /> sock_ioctl+0x3ef/0x650 net/socket.c:1321<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl fs/ioctl.c:856 [inline]<br /> __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81<br /> entry_SYSCALL_64_after_hwframe+0x64/0xce<br /> RIP: 0033:0x7f172b262b8d<br /> Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d<br /> RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003<br /> RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> devlink: fix possible use-after-free and memory leaks in devlink_init()<br /> <br /> The pernet operations structure for the subsystem must be registered<br /> before registering the generic netlink family.<br /> <br /> Make an unregister in case of unsuccessful registration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: sr: fix possible use-after-free and null-ptr-deref<br /> <br /> The pernet operations structure for the subsystem must be registered<br /> before registering the generic netlink family.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> afs: Increase buffer size in afs_update_volume_status()<br /> <br /> The max length of volume-&gt;vid value is 20 characters.<br /> So increase idbuf[] size up to 24 to avoid overflow.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.<br /> <br /> [DH: Actually, it&amp;#39;s 20 + NUL, so increase it to 24 and use snprintf()]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix racing between bpf_timer_cancel_and_free and bpf_timer_cancel<br /> <br /> The following race is possible between bpf_timer_cancel_and_free<br /> and bpf_timer_cancel. It will lead a UAF on the timer-&gt;timer.<br /> <br /> bpf_timer_cancel();<br /> spin_lock();<br /> t = timer-&gt;time;<br /> spin_unlock();<br /> <br /> bpf_timer_cancel_and_free();<br /> spin_lock();<br /> t = timer-&gt;timer;<br /> timer-&gt;timer = NULL;<br /> spin_unlock();<br /> hrtimer_cancel(&amp;t-&gt;timer);<br /> kfree(t);<br /> <br /> /* UAF on t */<br /> hrtimer_cancel(&amp;t-&gt;timer);<br /> <br /> In bpf_timer_cancel_and_free, this patch frees the timer-&gt;timer<br /> after a rcu grace period. This requires a rcu_head addition<br /> to the "struct bpf_hrtimer". Another kfree(t) happens in bpf_timer_init,<br /> this does not need a kfree_rcu because it is still under the<br /> spin_lock and timer-&gt;timer has not been visible by others yet.<br /> <br /> In bpf_timer_cancel, rcu_read_lock() is added because this helper<br /> can be used in a non rcu critical section context (e.g. from<br /> a sleepable bpf prog). Other timer-&gt;timer usages in helpers.c<br /> have been audited, bpf_timer_cancel() is the only place where<br /> timer-&gt;timer is used outside of the spin_lock.<br /> <br /> Another solution considered is to mark a t-&gt;flag in bpf_timer_cancel<br /> and clear it after hrtimer_cancel() is done. In bpf_timer_cancel_and_free,<br /> it busy waits for the flag to be cleared before kfree(t). This patch<br /> goes with a straight forward solution and frees timer-&gt;timer after<br /> a rcu grace period.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries/iommu: DLPAR add doesn&amp;#39;t completely initialize pci_controller<br /> <br /> When a PCI device is dynamically added, the kernel oopses with a NULL<br /> pointer dereference:<br /> <br /> BUG: Kernel NULL pointer dereference on read at 0x00000030<br /> Faulting instruction address: 0xc0000000006bbe5c<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse<br /> CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66<br /> Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries<br /> NIP: c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8<br /> REGS: c00000009924f240 TRAP: 0300 Not tainted (6.7.0-203405+)<br /> MSR: 8000000000009033 CR: 24002220 XER: 20040006<br /> CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0<br /> ...<br /> NIP sysfs_add_link_to_group+0x34/0x94<br /> LR iommu_device_link+0x5c/0x118<br /> Call Trace:<br /> iommu_init_device+0x26c/0x318 (unreliable)<br /> iommu_device_link+0x5c/0x118<br /> iommu_init_device+0xa8/0x318<br /> iommu_probe_device+0xc0/0x134<br /> iommu_bus_notifier+0x44/0x104<br /> notifier_call_chain+0xb8/0x19c<br /> blocking_notifier_call_chain+0x64/0x98<br /> bus_notify+0x50/0x7c<br /> device_add+0x640/0x918<br /> pci_device_add+0x23c/0x298<br /> of_create_pci_dev+0x400/0x884<br /> of_scan_pci_dev+0x124/0x1b0<br /> __of_scan_bus+0x78/0x18c<br /> pcibios_scan_phb+0x2a4/0x3b0<br /> init_phb_dynamic+0xb8/0x110<br /> dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]<br /> add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]<br /> kobj_attr_store+0x2c/0x48<br /> sysfs_kf_write+0x64/0x78<br /> kernfs_fop_write_iter+0x1b0/0x290<br /> vfs_write+0x350/0x4a0<br /> ksys_write+0x84/0x140<br /> system_call_exception+0x124/0x330<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Commit a940904443e4 ("powerpc/iommu: Add iommu_ops to report capabilities<br /> and allow blocking domains") broke DLPAR add of PCI devices.<br /> <br /> The above added iommu_device structure to pci_controller. During<br /> system boot, PCI devices are discovered and this newly added iommu_device<br /> structure is initialized by a call to iommu_device_register().<br /> <br /> During DLPAR add of a PCI device, a new pci_controller structure is<br /> allocated but there are no calls made to iommu_device_register()<br /> interface.<br /> <br /> Fix is to register the iommu device during DLPAR add as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: act_mirred: use the backlog for mirred ingress<br /> <br /> The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog<br /> for nested calls to mirred ingress") hangs our testing VMs every 10 or so<br /> runs, with the familiar tcp_v4_rcv -&gt; tcp_v4_rcv deadlock reported by<br /> lockdep.<br /> <br /> The problem as previously described by Davide (see Link) is that<br /> if we reverse flow of traffic with the redirect (egress -&gt; ingress)<br /> we may reach the same socket which generated the packet. And we may<br /> still be holding its socket lock. The common solution to such deadlocks<br /> is to put the packet in the Rx backlog, rather than run the Rx path<br /> inline. Do that for all egress -&gt; ingress reversals, not just once<br /> we started to nest mirred calls.<br /> <br /> In the past there was a concern that the backlog indirection will<br /> lead to loss of error reporting / less accurate stats. But the current<br /> workaround does not seem to address the issue.