Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Disable IRQ before init_fn() for nonboot CPUs<br /> <br /> Disable IRQ before init_fn() for nonboot CPUs when hotplug, in order to<br /> silence such warnings (and also avoid potential errors due to unexpected<br /> interrupts):<br /> <br /> WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198<br /> pc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0<br /> a0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000<br /> a4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c<br /> t0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e<br /> t4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000<br /> t8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001<br /> s1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001<br /> s5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8<br /> ra: 90000000047bd56c tlb_init+0x24c/0x528<br /> ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280<br /> CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)<br /> PRMD: 00000000 (PPLV0 -PIE -PWE)<br /> EUEN: 00000000 (-FPE -SXE -ASXE -BTE)<br /> ECFG: 00071000 (LIE=12 VS=7)<br /> ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)<br /> PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)<br /> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198<br /> Stack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000<br /> 900000010039fa30 0000000000000000 900000010039fa38 900000000619a140<br /> 9000000006456888 9000000006456880 900000010039f950 0000000000000001<br /> 0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700<br /> 0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003<br /> 0000000000040000 9000000007930370 0000000002b90000 0000000000000004<br /> 9000000006366000 900000000619a140 0000000000000000 0000000000000004<br /> 0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940<br /> 9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8<br /> 00000000000000b0 0000000000000000 0000000000000000 0000000000071000<br /> ...<br /> Call Trace:<br /> [] show_stack+0x48/0x1a0<br /> [] dump_stack_lvl+0x84/0xcc<br /> [] __warn+0x8c/0x1e0<br /> [] report_bug+0x1b4/0x280<br /> [] do_bp+0x2d0/0x480<br /> [] handle_bp+0x120/0x1c0<br /> [] rcu_cpu_starting+0x214/0x280<br /> [] tlb_init+0x248/0x528<br /> [] per_cpu_trap_init+0x124/0x160<br /> [] cpu_probe+0x494/0xa00<br /> [] start_secondary+0x3c/0xc0<br /> [] smpboot_entry+0x50/0x58

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/hfi1: Fix sdma.h tx-&gt;num_descs off-by-one error<br /> <br /> Unfortunately the commit `fd8958efe877` introduced another error<br /> causing the `descs` array to overflow. This reults in further crashes<br /> easily reproducible by `sendmsg` system call.<br /> <br /> [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI<br /> [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]<br /> --<br /> [ 1080.974535] Call Trace:<br /> [ 1080.976990] <br /> [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]<br /> [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]<br /> [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1]<br /> [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]<br /> [ 1081.046978] dev_hard_start_xmit+0xc4/0x210<br /> --<br /> [ 1081.148347] __sys_sendmsg+0x59/0xa0<br /> <br /> crash&gt; ipoib_txreq 0xffff9cfeba229f00<br /> struct ipoib_txreq {<br /> txreq = {<br /> list = {<br /> next = 0xffff9cfeba229f00,<br /> prev = 0xffff9cfeba229f00<br /> },<br /> descp = 0xffff9cfeba229f40,<br /> coalesce_buf = 0x0,<br /> wait = 0xffff9cfea4e69a48,<br /> complete = 0xffffffffc0fe0760 ,<br /> packet_len = 0x46d,<br /> tlen = 0x0,<br /> num_desc = 0x0,<br /> desc_limit = 0x6,<br /> next_descq_idx = 0x45c,<br /> coalesce_idx = 0x0,<br /> flags = 0x0,<br /> descs = {{<br /> qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)<br /> }, {<br /> qw = { 0x3800014231b108, 0x4}<br /> }, {<br /> qw = { 0x310000e4ee0fcf0, 0x8}<br /> }, {<br /> qw = { 0x3000012e9f8000, 0x8}<br /> }, {<br /> qw = { 0x59000dfb9d0000, 0x8}<br /> }, {<br /> qw = { 0x78000e02e40000, 0x8}<br /> }}<br /> },<br /> sdma_hdr = 0x400300015528b000,

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.