Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> l2tp: avoid one data-race in l2tp_tunnel_del_work()<br /> <br /> We should read sk-&gt;sk_socket only when dealing with kernel sockets.<br /> <br /> syzbot reported the following data-race:<br /> <br /> BUG: KCSAN: data-race in l2tp_tunnel_del_work / sk_common_release<br /> <br /> write to 0xffff88811c182b20 of 8 bytes by task 5365 on cpu 0:<br /> sk_set_socket include/net/sock.h:2092 [inline]<br /> sock_orphan include/net/sock.h:2118 [inline]<br /> sk_common_release+0xae/0x230 net/core/sock.c:4003<br /> udp_lib_close+0x15/0x20 include/net/udp.h:325<br /> inet_release+0xce/0xf0 net/ipv4/af_inet.c:437<br /> __sock_release net/socket.c:662 [inline]<br /> sock_close+0x6b/0x150 net/socket.c:1455<br /> __fput+0x29b/0x650 fs/file_table.c:468<br /> ____fput+0x1c/0x30 fs/file_table.c:496<br /> task_work_run+0x131/0x1a0 kernel/task_work.c:233<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> __exit_to_user_mode_loop kernel/entry/common.c:44 [inline]<br /> exit_to_user_mode_loop+0x1fe/0x740 kernel/entry/common.c:75<br /> __exit_to_user_mode_prepare include/linux/irq-entry-common.h:226 [inline]<br /> syscall_exit_to_user_mode_prepare include/linux/irq-entry-common.h:256 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:159 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:194 [inline]<br /> do_syscall_64+0x1e1/0x2b0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff88811c182b20 of 8 bytes by task 827 on cpu 1:<br /> l2tp_tunnel_del_work+0x2f/0x1a0 net/l2tp/l2tp_core.c:1418<br /> process_one_work kernel/workqueue.c:3257 [inline]<br /> process_scheduled_works+0x4ce/0x9d0 kernel/workqueue.c:3340<br /> worker_thread+0x582/0x770 kernel/workqueue.c:3421<br /> kthread+0x489/0x510 kernel/kthread.c:463<br /> ret_from_fork+0x149/0x290 arch/x86/kernel/process.c:158<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246<br /> <br /> value changed: 0xffff88811b818000 -&gt; 0x0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: provide a net pointer to __skb_flow_dissect()<br /> <br /> After 3cbf4ffba5ee ("net: plumb network namespace into __skb_flow_dissect")<br /> we have to provide a net pointer to __skb_flow_dissect(),<br /> either via skb-&gt;dev, skb-&gt;sk, or a user provided pointer.<br /> <br /> In the following case, syzbot was able to cook a bare skb.<br /> <br /> WARNING: net/core/flow_dissector.c:1131 at __skb_flow_dissect+0xb57/0x68b0 net/core/flow_dissector.c:1131, CPU#1: syz.2.1418/11053<br /> Call Trace:<br /> <br /> bond_flow_dissect drivers/net/bonding/bond_main.c:4093 [inline]<br /> __bond_xmit_hash+0x2d7/0xba0 drivers/net/bonding/bond_main.c:4157<br /> bond_xmit_hash_xdp drivers/net/bonding/bond_main.c:4208 [inline]<br /> bond_xdp_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5139 [inline]<br /> bond_xdp_get_xmit_slave+0x1fd/0x710 drivers/net/bonding/bond_main.c:5515<br /> xdp_master_redirect+0x13f/0x2c0 net/core/filter.c:4388<br /> bpf_prog_run_xdp include/net/xdp.h:700 [inline]<br /> bpf_test_run+0x6b2/0x7d0 net/bpf/test_run.c:421<br /> bpf_prog_test_run_xdp+0x795/0x10e0 net/bpf/test_run.c:1390<br /> bpf_prog_test_run+0x2c7/0x340 kernel/bpf/syscall.c:4703<br /> __sys_bpf+0x562/0x860 kernel/bpf/syscall.c:6182<br /> __do_sys_bpf kernel/bpf/syscall.c:6274 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:6272 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:6272<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xec/0xf80 arch/x86/entry/syscall_64.c:94

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Fix refcount warning on event-&gt;mmap_count increment<br /> <br /> When calling refcount_inc(&amp;event-&gt;mmap_count) inside perf_mmap_rb(), the<br /> following warning is triggered:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: lib/refcount.c:25<br /> <br /> PoC:<br /> <br /> struct perf_event_attr attr = {0};<br /> int fd = syscall(__NR_perf_event_open, &amp;attr, 0, -1, -1, 0);<br /> mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);<br /> int victim = syscall(__NR_perf_event_open, &amp;attr, 0, -1, fd,<br /> PERF_FLAG_FD_OUTPUT);<br /> mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0);<br /> <br /> This occurs when creating a group member event with the flag<br /> PERF_FLAG_FD_OUTPUT. The group leader should be mmap-ed and then mmap-ing<br /> the event triggers the warning.<br /> <br /> Since the event has copied the output_event in perf_event_set_output(),<br /> event-&gt;rb is set. As a result, perf_mmap_rb() calls<br /> refcount_inc(&amp;event-&gt;mmap_count) when event-&gt;mmap_count = 0.<br /> <br /> Disallow the case when event-&gt;mmap_count = 0. This also prevents two<br /> events from updating the same user_page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netdevsim: fix a race issue related to the operation on bpf_bound_progs list<br /> <br /> The netdevsim driver lacks a protection mechanism for operations on the<br /> bpf_bound_progs list. When the nsim_bpf_create_prog() performs<br /> list_add_tail, it is possible that nsim_bpf_destroy_prog() is<br /> simultaneously performs list_del. Concurrent operations on the list may<br /> lead to list corruption and trigger a kernel crash as follows:<br /> <br /> [ 417.290971] kernel BUG at lib/list_debug.c:62!<br /> [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1<br /> [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 417.291007] Workqueue: events bpf_prog_free_deferred<br /> [ 417.291021] RIP: 0010:__list_del_entry_valid_or_report+0xa7/0xc0<br /> [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8<br /> [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246<br /> [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000<br /> [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180<br /> [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003<br /> [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20<br /> [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000<br /> [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000<br /> [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0<br /> [ 417.291088] PKRU: 55555554<br /> [ 417.291091] Call Trace:<br /> [ 417.291096] <br /> [ 417.291103] nsim_bpf_destroy_prog+0x31/0x80 [netdevsim]<br /> [ 417.291154] __bpf_prog_offload_destroy+0x2a/0x80<br /> [ 417.291163] bpf_prog_dev_bound_destroy+0x6f/0xb0<br /> [ 417.291171] bpf_prog_free_deferred+0x18e/0x1a0<br /> [ 417.291178] process_one_work+0x18a/0x3a0<br /> [ 417.291188] worker_thread+0x27b/0x3a0<br /> [ 417.291197] ? __pfx_worker_thread+0x10/0x10<br /> [ 417.291207] kthread+0xe5/0x120<br /> [ 417.291214] ? __pfx_kthread+0x10/0x10<br /> [ 417.291221] ret_from_fork+0x31/0x50<br /> [ 417.291230] ? __pfx_kthread+0x10/0x10<br /> [ 417.291236] ret_from_fork_asm+0x1a/0x30<br /> [ 417.291246] <br /> <br /> Add a mutex lock, to prevent simultaneous addition and deletion operations<br /> on the list.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT<br /> <br /> A null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key<br /> initialization fails:<br /> <br /> ==================================================================<br /> KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]<br /> CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2<br /> RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]<br /> RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401<br /> Call Trace:<br /> <br /> sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189<br /> sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111<br /> sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217<br /> sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787<br /> sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]<br /> sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169<br /> sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052<br /> sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88<br /> sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243<br /> sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127<br /> <br /> The issue is triggered when sctp_auth_asoc_init_active_key() fails in<br /> sctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the<br /> command sequence is currently:<br /> <br /> - SCTP_CMD_PEER_INIT<br /> - SCTP_CMD_TIMER_STOP (T1_INIT)<br /> - SCTP_CMD_TIMER_START (T1_COOKIE)<br /> - SCTP_CMD_NEW_STATE (COOKIE_ECHOED)<br /> - SCTP_CMD_ASSOC_SHKEY<br /> - SCTP_CMD_GEN_COOKIE_ECHO<br /> <br /> If SCTP_CMD_ASSOC_SHKEY fails, asoc-&gt;shkey remains NULL, while<br /> asoc-&gt;peer.auth_capable and asoc-&gt;peer.peer_chunks have already been set by<br /> SCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL<br /> to be queued by sctp_datamsg_from_user().<br /> <br /> Since command interpretation stops on failure, no COOKIE_ECHO should been<br /> sent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already<br /> been started, and it may enqueue a COOKIE_ECHO into the outqueue later. As<br /> a result, the DATA chunk can be transmitted together with the COOKIE_ECHO<br /> in sctp_outq_flush_data(), leading to the observed issue.<br /> <br /> Similar to the other places where it calls sctp_auth_asoc_init_active_key()<br /> right after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY<br /> immediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting<br /> T1_COOKIE. This ensures that if shared key generation fails, authenticated<br /> DATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,<br /> giving the client another chance to process INIT_ACK and retry key setup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: annotate data-race in ndisc_router_discovery()<br /> <br /> syzbot found that ndisc_router_discovery() could read and write<br /> in6_dev-&gt;ra_mtu without holding a lock [1]<br /> <br /> This looks fine, IFLA_INET6_RA_MTU is best effort.<br /> <br /> Add READ_ONCE()/WRITE_ONCE() to document the race.<br /> <br /> Note that we might also reject illegal MTU values<br /> (mtu skb-&gt;dev-&gt;mtu) in a future patch.<br /> <br /> [1]<br /> BUG: KCSAN: data-race in ndisc_router_discovery / ndisc_router_discovery<br /> <br /> read to 0xffff888119809c20 of 4 bytes by task 25817 on cpu 1:<br /> ndisc_router_discovery+0x151d/0x1c90 net/ipv6/ndisc.c:1558<br /> ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841<br /> icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989<br /> ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79<br /> ...<br /> <br /> write to 0xffff888119809c20 of 4 bytes by task 25816 on cpu 0:<br /> ndisc_router_discovery+0x155a/0x1c90 net/ipv6/ndisc.c:1559<br /> ndisc_rcv+0x2ad/0x3d0 net/ipv6/ndisc.c:1841<br /> icmpv6_rcv+0xe5a/0x12f0 net/ipv6/icmp.c:989<br /> ip6_protocol_deliver_rcu+0xb2a/0x10d0 net/ipv6/ip6_input.c:438<br /> ip6_input_finish+0xf0/0x1d0 net/ipv6/ip6_input.c:489<br /> NF_HOOK include/linux/netfilter.h:318 [inline]<br /> ip6_input+0x5e/0x140 net/ipv6/ip6_input.c:500<br /> ip6_mc_input+0x27c/0x470 net/ipv6/ip6_input.c:590<br /> dst_input include/net/dst.h:474 [inline]<br /> ip6_rcv_finish+0x336/0x340 net/ipv6/ip6_input.c:79<br /> ...<br /> <br /> value changed: 0x00000000 -&gt; 0xe5400659

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: debugfs: initialize src_node and dst_node to empty strings<br /> <br /> The debugfs_create_str() API assumes that the string pointer is either NULL<br /> or points to valid kmalloc() memory. Leaving the pointer uninitialized can<br /> cause problems.<br /> <br /> Initialize src_node and dst_node to empty strings before creating the<br /> debugfs entries to guarantee that reads and writes are safe.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: Reduce TSN TX packet buffer from 7KB to 5KB per queue<br /> <br /> The previous 7 KB per queue caused TX unit hangs under heavy<br /> timestamping load. Reducing to 5 KB avoids these hangs and matches<br /> the TSN recommendation in I225/I226 SW User Manual Section 7.5.4.<br /> <br /> The 8 KB "freed" by this change is currently unused. This reduction<br /> is not expected to impact throughput, as the i226 is PCIe-limited<br /> for small TSN packets rather than TX-buffer-limited.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: add missing ice_deinit_hw() in devlink reinit path<br /> <br /> devlink-reload results in ice_init_hw failed error, and then removing<br /> the ice driver causes a NULL pointer dereference.<br /> <br /> [ +0.102213] ice 0000:ca:00.0: ice_init_hw failed: -16<br /> ...<br /> [ +0.000001] Call Trace:<br /> [ +0.000003] <br /> [ +0.000006] ice_unload+0x8f/0x100 [ice]<br /> [ +0.000081] ice_remove+0xba/0x300 [ice]<br /> <br /> Commit 1390b8b3d2be ("ice: remove duplicate call to ice_deinit_hw() on<br /> error paths") removed ice_deinit_hw() from ice_deinit_dev(). As a result<br /> ice_devlink_reinit_down() no longer calls ice_deinit_hw(), but<br /> ice_devlink_reinit_up() still calls ice_init_hw(). Since the control<br /> queues are not uninitialized, ice_init_hw() fails with -EBUSY.<br /> <br /> Add ice_deinit_hw() to ice_devlink_reinit_down() to correspond with<br /> ice_init_hw() in ice_devlink_reinit_up().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8m-blk-ctrl: Remove separate rst and clk mask for 8mq vpu<br /> <br /> For i.MX8MQ platform, the ADB in the VPUMIX domain has no separate reset<br /> and clock enable bits, but is ungated and reset together with the VPUs.<br /> So we can&amp;#39;t reset G1 or G2 separately, it may led to the system hang.<br /> Remove rst_mask and clk_mask of imx8mq_vpu_blk_ctl_domain_data.<br /> Let imx8mq_vpu_power_notifier() do really vpu reset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: Fix not set tty-&gt;port race condition<br /> <br /> Revert commit bfc467db60b7 ("serial: remove redundant<br /> tty_port_link_device()") because the tty_port_link_device() is not<br /> redundant: the tty-&gt;port has to be confured before we call<br /> uart_configure_port(), otherwise user-space can open console without TTY<br /> linked to the driver.<br /> <br /> This tty_port_link_device() was added explicitly to avoid this exact<br /> issue in commit fb2b90014d78 ("tty: link tty and port before configuring<br /> it as console"), so offending commit basically reverted the fix saying<br /> it is redundant without addressing the actual race condition presented<br /> there.<br /> <br /> Reproducible always as tty-&gt;port warning on Qualcomm SoC with most of<br /> devices disabled, so with very fast boot, and one serial device being<br /> the console:<br /> <br /> printk: legacy console [ttyMSM0] enabled<br /> printk: legacy console [ttyMSM0] enabled<br /> printk: legacy bootconsole [qcom_geni0] disabled<br /> printk: legacy bootconsole [qcom_geni0] disabled<br /> ------------[ cut here ]------------<br /> tty_init_dev: ttyMSM driver does not set tty-&gt;port. This would crash the kernel. Fix the driver!<br /> WARNING: drivers/tty/tty_io.c:1414 at tty_init_dev.part.0+0x228/0x25c, CPU#2: systemd/1<br /> Modules linked in: socinfo tcsrcc_eliza gcc_eliza sm3_ce fuse ipv6<br /> CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G S 6.19.0-rc4-next-20260108-00024-g2202f4d30aa8 #73 PREEMPT<br /> Tainted: [S]=CPU_OUT_OF_SPEC<br /> Hardware name: Qualcomm Technologies, Inc. Eliza (DT)<br /> ...<br /> tty_init_dev.part.0 (drivers/tty/tty_io.c:1414 (discriminator 11)) (P)<br /> tty_open (arch/arm64/include/asm/atomic_ll_sc.h:95 (discriminator 3) drivers/tty/tty_io.c:2073 (discriminator 3) drivers/tty/tty_io.c:2120 (discriminator 3))<br /> chrdev_open (fs/char_dev.c:411)<br /> do_dentry_open (fs/open.c:962)<br /> vfs_open (fs/open.c:1094)<br /> do_open (fs/namei.c:4634)<br /> path_openat (fs/namei.c:4793)<br /> do_filp_open (fs/namei.c:4820)<br /> do_sys_openat2 (fs/open.c:1391 (discriminator 3))<br /> ...<br /> Starting Network Name Resolution...<br /> <br /> Apparently the flow with this small Yocto-based ramdisk user-space is:<br /> <br /> driver (qcom_geni_serial.c): user-space:<br /> ============================ ===========<br /> qcom_geni_serial_probe()<br /> uart_add_one_port()<br /> serial_core_register_port()<br /> serial_core_add_one_port()<br /> uart_configure_port()<br /> register_console()<br /> |<br /> | open console<br /> | ...<br /> | tty_init_dev()<br /> | driver-&gt;ports[idx] is NULL<br /> |<br /> tty_port_register_device_attr_serdev()<br /> tty_port_link_device() ports[idx]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/fpsimd: ptrace: Fix SVE writes on !SME systems<br /> <br /> When SVE is supported but SME is not supported, a ptrace write to the<br /> NT_ARM_SVE regset can place the tracee into an invalid state where<br /> (non-streaming) SVE register data is stored in FP_STATE_SVE format but<br /> TIF_SVE is clear. This can result in a later warning from<br /> fpsimd_restore_current_state(), e.g.<br /> <br /> WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748<br /> <br /> When this happens, fpsimd_restore_current_state() will set TIF_SVE,<br /> placing the task into the correct state. This occurs before any other<br /> check of TIF_SVE can possibly occur, as other checks of TIF_SVE only<br /> happen while the FPSIMD/SVE/SME state is live. Thus, aside from the<br /> warning, there is no functional issue.<br /> <br /> This bug was introduced during rework to error handling in commit:<br /> <br /> 9f8bf718f2923 ("arm64/fpsimd: ptrace: Gracefully handle errors")<br /> <br /> ... where the setting of TIF_SVE was moved into a block which is only<br /> executed when system_supports_sme() is true.<br /> <br /> Fix this by removing the system_supports_sme() check. This ensures that<br /> TIF_SVE is set for (SVE-formatted) writes to NT_ARM_SVE, at the cost of<br /> unconditionally manipulating the tracee&amp;#39;s saved svcr value. The<br /> manipulation of svcr is benign and inexpensive, and we already do<br /> similar elsewhere (e.g. during signal handling), so I don&amp;#39;t think it&amp;#39;s<br /> worth guarding this with system_supports_sme() checks.<br /> <br /> Aside from the above, there is no functional change. The &amp;#39;type&amp;#39; argument<br /> to sve_set_common() is only set to ARM64_VEC_SME (in ssve_set())) when<br /> system_supports_sme(), so the ARM64_VEC_SME case in the switch statement<br /> is still unreachable when !system_supports_sme(). When<br /> CONFIG_ARM64_SME=n, the only caller of sve_set_common() is sve_set(),<br /> and the compiler can constant-fold for the case where type is<br /> ARM64_VEC_SVE, removing the logic for other cases.