Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> genetlink: fix genl_bind() invoking bind() after -EPERM<br /> <br /> Per family bind/unbind callbacks were introduced to allow families<br /> to track multicast group consumer presence, e.g. to start or stop<br /> producing events depending on listeners.<br /> <br /> However, in genl_bind() the bind() callback was invoked even if<br /> capability checks failed and ret was set to -EPERM. This means that<br /> callbacks could run on behalf of unauthorized callers while the<br /> syscall still returned failure to user space.<br /> <br /> Fix this by only invoking bind() after "if (ret) break;" check<br /> i.e. after permission checks have succeeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pcmcia: Add error handling for add_interval() in do_validate_mem()<br /> <br /> In the do_validate_mem(), the call to add_interval() does not<br /> handle errors. If kmalloc() fails in add_interval(), it could<br /> result in a null pointer being inserted into the linked list,<br /> leading to illegal memory access when sub_interval() is called<br /> next.<br /> <br /> This patch adds an error handling for the add_interval(). If<br /> add_interval() returns an error, the function will return early<br /> with the error code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees<br /> <br /> When we don&amp;#39;t have a clock specified in the device tree, we have no way to<br /> ensure the BAM is on. This is often the case for remotely-controlled or<br /> remotely-powered BAM instances. In this case, we need to read num-channels<br /> from the DT to have all the necessary information to complete probing.<br /> <br /> However, at the moment invalid device trees without clock and without<br /> num-channels still continue probing, because the error handling is missing<br /> return statements. The driver will then later try to read the number of<br /> channels from the registers. This is unsafe, because it relies on boot<br /> firmware and lucky timing to succeed. Unfortunately, the lack of proper<br /> error handling here has been abused for several Qualcomm SoCs upstream,<br /> causing early boot crashes in several situations [1, 2].<br /> <br /> Avoid these early crashes by erroring out when any of the required DT<br /> properties are missing. Note that this will break some of the existing DTs<br /> upstream (mainly BAM instances related to the crypto engine). However,<br /> clearly these DTs have never been tested properly, since the error in the<br /> kernel log was just ignored. It&amp;#39;s safer to disable the crypto engine for<br /> these broken DTBs.<br /> <br /> [1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/<br /> [2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs/localio: restore creds before releasing pageio data<br /> <br /> Otherwise if the nfsd filecache code releases the nfsd_file<br /> immediately, it can trigger the BUG_ON(cred == current-&gt;cred) in<br /> __put_cred() when it puts the nfsd_file-&gt;nf_file-&gt;f-cred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: phy: transfer phy_config_inband() locking responsibility to phylink<br /> <br /> Problem description<br /> ===================<br /> <br /> Lockdep reports a possible circular locking dependency (AB/BA) between<br /> &amp;pl-&gt;state_mutex and &amp;phy-&gt;lock, as follows.<br /> <br /> phylink_resolve() // acquires &amp;pl-&gt;state_mutex<br /> -&gt; phylink_major_config()<br /> -&gt; phy_config_inband() // acquires &amp;pl-&gt;phydev-&gt;lock<br /> <br /> whereas all the other call sites where &amp;pl-&gt;state_mutex and<br /> &amp;pl-&gt;phydev-&gt;lock have the locking scheme reversed. Everywhere else,<br /> &amp;pl-&gt;phydev-&gt;lock is acquired at the top level, and &amp;pl-&gt;state_mutex at<br /> the lower level. A clear example is phylink_bringup_phy().<br /> <br /> The outlier is the newly introduced phy_config_inband() and the existing<br /> lock order is the correct one. To understand why it cannot be the other<br /> way around, it is sufficient to consider phylink_phy_change(), phylink&amp;#39;s<br /> callback from the PHY device&amp;#39;s phy-&gt;phy_link_change() virtual method,<br /> invoked by the PHY state machine.<br /> <br /> phy_link_up() and phy_link_down(), the (indirect) callers of<br /> phylink_phy_change(), are called with &amp;phydev-&gt;lock acquired.<br /> Then phylink_phy_change() acquires its own &amp;pl-&gt;state_mutex, to<br /> serialize changes made to its pl-&gt;phy_state and pl-&gt;link_config.<br /> So all other instances of &amp;pl-&gt;state_mutex and &amp;phydev-&gt;lock must be<br /> consistent with this order.<br /> <br /> Problem impact<br /> ==============<br /> <br /> I think the kernel runs a serious deadlock risk if an existing<br /> phylink_resolve() thread, which results in a phy_config_inband() call,<br /> is concurrent with a phy_link_up() or phy_link_down() call, which will<br /> deadlock on &amp;pl-&gt;state_mutex in phylink_phy_change(). Practically<br /> speaking, the impact may be limited by the slow speed of the medium<br /> auto-negotiation protocol, which makes it unlikely for the current state<br /> to still be unresolved when a new one is detected, but I think the<br /> problem is there. Nonetheless, the problem was discovered using lockdep.<br /> <br /> Proposed solution<br /> =================<br /> <br /> Practically speaking, the phy_config_inband() requirement of having<br /> phydev-&gt;lock acquired must transfer to the caller (phylink is the only<br /> caller). There, it must bubble up until immediately before<br /> &amp;pl-&gt;state_mutex is acquired, for the cases where that takes place.<br /> <br /> Solution details, considerations, notes<br /> =======================================<br /> <br /> This is the phy_config_inband() call graph:<br /> <br /> sfp_upstream_ops :: connect_phy()<br /> |<br /> v<br /> phylink_sfp_connect_phy()<br /> |<br /> v<br /> phylink_sfp_config_phy()<br /> |<br /> | sfp_upstream_ops :: module_insert()<br /> | |<br /> | v<br /> | phylink_sfp_module_insert()<br /> | |<br /> | | sfp_upstream_ops :: module_start()<br /> | | |<br /> | | v<br /> | | phylink_sfp_module_start()<br /> | | |<br /> | v v<br /> | phylink_sfp_config_optical()<br /> phylink_start() | |<br /> | phylink_resume() v v<br /> | | phylink_sfp_set_config()<br /> | | |<br /> v v v<br /> phylink_mac_initial_config()<br /> | phylink_resolve()<br /> | | phylink_ethtool_ksettings_set()<br /> v v v<br /> phylink_major_config()<br /> |<br /> v<br /> phy_config_inband()<br /> <br /> phylink_major_config() caller #1, phylink_mac_initial_config(), does not<br /> acquire &amp;pl-&gt;state_mutex nor do its callers. It must acquire<br /> &amp;pl-&gt;phydev-&gt;lock prior to calling phylink_major_config().<br /> <br /> phylink_major_config() caller #2, phylink_resolve() acquires<br /> &amp;pl-&gt;state_mutex, thus also needs to acquire &amp;pl-&gt;phydev-&gt;lock.<br /> <br /> phylink_major_config() caller #3, phylink_ethtool_ksettings_set(), is<br /> completely uninteresting, because it only call<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix out-of-bounds dynptr write in bpf_crypto_crypt<br /> <br /> Stanislav reported that in bpf_crypto_crypt() the destination dynptr&amp;#39;s<br /> size is not validated to be at least as large as the source dynptr&amp;#39;s<br /> size before calling into the crypto backend with &amp;#39;len = src_len&amp;#39;. This<br /> can result in an OOB write when the destination is smaller than the<br /> source.<br /> <br /> Concretely, in mentioned function, psrc and pdst are both linear<br /> buffers fetched from each dynptr:<br /> <br /> psrc = __bpf_dynptr_data(src, src_len);<br /> [...]<br /> pdst = __bpf_dynptr_data_rw(dst, dst_len);<br /> [...]<br /> err = decrypt ?<br /> ctx-&gt;type-&gt;decrypt(ctx-&gt;tfm, psrc, pdst, src_len, piv) :<br /> ctx-&gt;type-&gt;encrypt(ctx-&gt;tfm, psrc, pdst, src_len, piv);<br /> <br /> The crypto backend expects pdst to be large enough with a src_len length<br /> that can be written. Add an additional src_len &gt; dst_len check and bail<br /> out if it&amp;#39;s the case. Note that these kfuncs are accessible under root<br /> privileges only.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path<br /> <br /> If request_irq() in i40e_vsi_request_irq_msix() fails in an iteration<br /> later than the first, the error path wants to free the IRQs requested<br /> so far. However, it uses the wrong dev_id argument for free_irq(), so<br /> it does not free the IRQs correctly and instead triggers the warning:<br /> <br /> Trying to free already-free IRQ 173<br /> WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0<br /> Modules linked in: i40e(+) [...]<br /> CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)<br /> Hardware name: [...]<br /> RIP: 0010:__free_irq+0x192/0x2c0<br /> [...]<br /> Call Trace:<br /> <br /> free_irq+0x32/0x70<br /> i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]<br /> i40e_vsi_request_irq+0x79/0x80 [i40e]<br /> i40e_vsi_open+0x21f/0x2f0 [i40e]<br /> i40e_open+0x63/0x130 [i40e]<br /> __dev_open+0xfc/0x210<br /> __dev_change_flags+0x1fc/0x240<br /> netif_change_flags+0x27/0x70<br /> do_setlink.isra.0+0x341/0xc70<br /> rtnl_newlink+0x468/0x860<br /> rtnetlink_rcv_msg+0x375/0x450<br /> netlink_rcv_skb+0x5c/0x110<br /> netlink_unicast+0x288/0x3c0<br /> netlink_sendmsg+0x20d/0x430<br /> ____sys_sendmsg+0x3a2/0x3d0<br /> ___sys_sendmsg+0x99/0xe0<br /> __sys_sendmsg+0x8a/0xf0<br /> do_syscall_64+0x82/0x2c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [...]<br /> <br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Use the same dev_id for free_irq() as for request_irq().<br /> <br /> I tested this with inserting code to fail intentionally.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock-&gt;cork.<br /> <br /> syzbot reported the splat below. [0]<br /> <br /> The repro does the following:<br /> <br /> 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes)<br /> 2. Attach the prog to a SOCKMAP<br /> 3. Add a socket to the SOCKMAP<br /> 4. Activate fault injection<br /> 5. Send data less than cork_bytes<br /> <br /> At 5., the data is carried over to the next sendmsg() as it is<br /> smaller than the cork_bytes specified by bpf_msg_cork_bytes().<br /> <br /> Then, tcp_bpf_send_verdict() tries to allocate psock-&gt;cork to hold<br /> the data, but this fails silently due to fault injection + __GFP_NOWARN.<br /> <br /> If the allocation fails, we need to revert the sk-&gt;sk_forward_alloc<br /> change done by sk_msg_alloc().<br /> <br /> Let&amp;#39;s call sk_msg_free() when tcp_bpf_send_verdict fails to allocate<br /> psock-&gt;cork.<br /> <br /> The "*copied" also needs to be updated such that a proper error can<br /> be returned to the caller, sendmsg. It fails to allocate psock-&gt;cork.<br /> Nothing has been corked so far, so this patch simply sets "*copied"<br /> to 0.<br /> <br /> [0]:<br /> WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025<br /> RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156<br /> Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc<br /> RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246<br /> RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80<br /> RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000<br /> RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4<br /> R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380<br /> R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872<br /> FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0<br /> Call Trace:<br /> <br /> __sk_destruct+0x86/0x660 net/core/sock.c:2339<br /> rcu_do_batch kernel/rcu/tree.c:2605 [inline]<br /> rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861<br /> handle_softirqs+0x286/0x870 kernel/softirq.c:579<br /> __do_softirq kernel/softirq.c:613 [inline]<br /> invoke_softirq kernel/softirq.c:453 [inline]<br /> __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680<br /> irq_exit_rcu+0x9/0x30 kernel/softirq.c:696<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline]<br /> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Silence warning when chunk allocation fails in trace_pid_write<br /> <br /> Syzkaller trigger a fault injection warning:<br /> <br /> WARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0<br /> Modules linked in:<br /> CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0<br /> Tainted: [U]=USER<br /> Hardware name: Google Compute Engine/Google Compute Engine<br /> RIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294<br /> Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff<br /> RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283<br /> RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000<br /> RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001<br /> RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000<br /> R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef<br /> R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0<br /> FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464<br /> register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]<br /> register_pid_events kernel/trace/trace_events.c:2354 [inline]<br /> event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425<br /> vfs_write+0x24c/0x1150 fs/read_write.c:677<br /> ksys_write+0x12b/0x250 fs/read_write.c:731<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> We can reproduce the warning by following the steps below:<br /> 1. echo 8 &gt;&gt; set_event_notrace_pid. Let tr-&gt;filtered_pids owns one pid<br /> and register sched_switch tracepoint.<br /> 2. echo &amp;#39; &amp;#39; &gt;&gt; set_event_pid, and perform fault injection during chunk<br /> allocation of trace_pid_list_alloc. Let pid_list with no pid and<br /> assign to tr-&gt;filtered_pids.<br /> 3. echo &amp;#39; &amp;#39; &gt;&gt; set_event_pid. Let pid_list is NULL and assign to<br /> tr-&gt;filtered_pids.<br /> 4. echo 9 &gt;&gt; set_event_pid, will trigger the double register<br /> sched_switch tracepoint warning.<br /> <br /> The reason is that syzkaller injects a fault into the chunk allocation<br /> in trace_pid_list_alloc, causing a failure in trace_pid_list_set, which<br /> may trigger double register of the same tracepoint. This only occurs<br /> when the system is about to crash, but to suppress this warning, let&amp;#39;s<br /> add failure handling logic to trace_pid_list_set.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/reclaim: avoid divide-by-zero in damon_reclaim_apply_parameters()<br /> <br /> When creating a new scheme of DAMON_RECLAIM, the calculation of<br /> &amp;#39;min_age_region&amp;#39; uses &amp;#39;aggr_interval&amp;#39; as the divisor, which may lead to<br /> division-by-zero errors. Fix it by directly returning -EINVAL when such a<br /> case occurs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> of_numa: fix uninitialized memory nodes causing kernel panic<br /> <br /> When there are memory-only nodes (nodes without CPUs), these nodes are not<br /> properly initialized, causing kernel panic during boot.<br /> <br /> of_numa_init<br /> of_numa_parse_cpu_nodes<br /> node_set(nid, numa_nodes_parsed);<br /> of_numa_parse_memory_nodes<br /> <br /> In of_numa_parse_cpu_nodes, numa_nodes_parsed gets updated only for nodes<br /> containing CPUs. Memory-only nodes should have been updated in<br /> of_numa_parse_memory_nodes, but they weren&amp;#39;t.<br /> <br /> Subsequently, when free_area_init() attempts to access NODE_DATA() for<br /> these uninitialized memory nodes, the kernel panics due to NULL pointer<br /> dereference.<br /> <br /> This can be reproduced on ARM64 QEMU with 1 CPU and 2 memory nodes:<br /> <br /> qemu-system-aarch64 \<br /> -cpu host -nographic \<br /> -m 4G -smp 1 \<br /> -machine virt,accel=kvm,gic-version=3,iommu=smmuv3 \<br /> -object memory-backend-ram,size=2G,id=mem0 \<br /> -object memory-backend-ram,size=2G,id=mem1 \<br /> -numa node,nodeid=0,memdev=mem0 \<br /> -numa node,nodeid=1,memdev=mem1 \<br /> -kernel $IMAGE \<br /> -hda $DISK \<br /> -append "console=ttyAMA0 root=/dev/vda rw earlycon"<br /> <br /> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x481fd010]<br /> [ 0.000000] Linux version 6.17.0-rc1-00001-gabb4b3daf18c-dirty (yintirui@local) (gcc (GCC) 12.3.1, GNU ld (GNU Binutils) 2.41) #52 SMP PREEMPT Mon Aug 18 09:49:40 CST 2025<br /> [ 0.000000] KASLR enabled<br /> [ 0.000000] random: crng init done<br /> [ 0.000000] Machine model: linux,dummy-virt<br /> [ 0.000000] efi: UEFI not found.<br /> [ 0.000000] earlycon: pl11 at MMIO 0x0000000009000000 (options &amp;#39;&amp;#39;)<br /> [ 0.000000] printk: legacy bootconsole [pl11] enabled<br /> [ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT<br /> [ 0.000000] NODE_DATA(0) allocated [mem 0xbfffd9c0-0xbfffffff]<br /> [ 0.000000] node 1 must be removed before remove section 23<br /> [ 0.000000] Zone ranges:<br /> [ 0.000000] DMA [mem 0x0000000040000000-0x00000000ffffffff]<br /> [ 0.000000] DMA32 empty<br /> [ 0.000000] Normal [mem 0x0000000100000000-0x000000013fffffff]<br /> [ 0.000000] Movable zone start for each node<br /> [ 0.000000] Early memory node ranges<br /> [ 0.000000] node 0: [mem 0x0000000040000000-0x00000000bfffffff]<br /> [ 0.000000] node 1: [mem 0x00000000c0000000-0x000000013fffffff]<br /> [ 0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff]<br /> [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0<br /> [ 0.000000] Mem abort info:<br /> [ 0.000000] ESR = 0x0000000096000004<br /> [ 0.000000] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 0.000000] SET = 0, FnV = 0<br /> [ 0.000000] EA = 0, S1PTW = 0<br /> [ 0.000000] FSC = 0x04: level 0 translation fault<br /> [ 0.000000] Data abort info:<br /> [ 0.000000] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> [ 0.000000] CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> [ 0.000000] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> [ 0.000000] [00000000000000a0] user address but active_mm is swapper<br /> [ 0.000000] Internal error: Oops: 0000000096000004 [#1] SMP<br /> [ 0.000000] Modules linked in:<br /> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.17.0-rc1-00001-g760c6dabf762-dirty #54 PREEMPT<br /> [ 0.000000] Hardware name: linux,dummy-virt (DT)<br /> [ 0.000000] pstate: 800000c5 (Nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 0.000000] pc : free_area_init+0x50c/0xf9c<br /> [ 0.000000] lr : free_area_init+0x5c0/0xf9c<br /> [ 0.000000] sp : ffffa02ca0f33c00<br /> [ 0.000000] x29: ffffa02ca0f33cb0 x28: 0000000000000000 x27: 0000000000000000<br /> [ 0.000000] x26: 4ec4ec4ec4ec4ec5 x25: 00000000000c0000 x24: 00000000000c0000<br /> [ 0.000000] x23: 0000000000040000 x22: 0000000000000000 x21: ffffa02ca0f3b368<br /> [ 0.000000] x20: ffffa02ca14c7b98 x19: 0000000000000000 x18: 0000000000000002<br /> [ 0.000000] x17: 000000000000cacc x16: 0000000000000001 x15: 0000000000000001<br /> [ 0.000000] x14: 0000000080000000 x13: 0000000000000018 x12: 0000000000000002<br /> [ 0.0<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: kexec: initialize kexec_buf struct in load_other_segments()<br /> <br /> Patch series "kexec: Fix invalid field access".<br /> <br /> The kexec_buf structure was previously declared without initialization. <br /> commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")<br /> added a field that is always read but not consistently populated by all<br /> architectures. This un-initialized field will contain garbage.<br /> <br /> This is also triggering a UBSAN warning when the uninitialized data was<br /> accessed:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: invalid-load in ./include/linux/kexec.h:210:10<br /> load of value 252 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> <br /> Zero-initializing kexec_buf at declaration ensures all fields are cleanly<br /> set, preventing future instances of uninitialized memory being used.<br /> <br /> An initial fix was already landed for arm64[0], and this patchset fixes<br /> the problem on the remaining arm64 code and on riscv, as raised by Mark.<br /> <br /> Discussions about this problem could be found at[1][2].<br /> <br /> <br /> This patch (of 3):<br /> <br /> The kexec_buf structure was previously declared without initialization.<br /> commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly")<br /> added a field that is always read but not consistently populated by all<br /> architectures. This un-initialized field will contain garbage.<br /> <br /> This is also triggering a UBSAN warning when the uninitialized data was<br /> accessed:<br /> <br /> ------------[ cut here ]------------<br /> UBSAN: invalid-load in ./include/linux/kexec.h:210:10<br /> load of value 252 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> <br /> Zero-initializing kexec_buf at declaration ensures all fields are<br /> cleanly set, preventing future instances of uninitialized memory being<br /> used.