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 /> mISDN: annotate data-race around dev-&gt;work<br /> <br /> dev-&gt;work can re read locklessly in mISDN_read()<br /> and mISDN_poll(). Add READ_ONCE()/WRITE_ONCE() annotations.<br /> <br /> BUG: KCSAN: data-race in mISDN_ioctl / mISDN_read<br /> <br /> write to 0xffff88812d848280 of 4 bytes by task 10864 on cpu 1:<br /> misdn_add_timer drivers/isdn/mISDN/timerdev.c:175 [inline]<br /> mISDN_ioctl+0x2fb/0x550 drivers/isdn/mISDN/timerdev.c:233<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xce/0x140 fs/ioctl.c:583<br /> __x64_sys_ioctl+0x43/0x50 fs/ioctl.c:583<br /> x64_sys_call+0x14b0/0x3000 arch/x86/include/generated/asm/syscalls_64.h:17<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> read to 0xffff88812d848280 of 4 bytes by task 10857 on cpu 0:<br /> mISDN_read+0x1f2/0x470 drivers/isdn/mISDN/timerdev.c:112<br /> do_loop_readv_writev fs/read_write.c:847 [inline]<br /> vfs_readv+0x3fb/0x690 fs/read_write.c:1020<br /> do_readv+0xe7/0x210 fs/read_write.c:1080<br /> __do_sys_readv fs/read_write.c:1165 [inline]<br /> __se_sys_readv fs/read_write.c:1162 [inline]<br /> __x64_sys_readv+0x45/0x50 fs/read_write.c:1162<br /> x64_sys_call+0x2831/0x3000 arch/x86/include/generated/asm/syscalls_64.h:20<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xd8/0x2c0 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> value changed: 0x00000000 -&gt; 0x00000001

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> io_uring/io-wq: check IO_WQ_BIT_EXIT inside work run loop<br /> <br /> Currently this is checked before running the pending work. Normally this<br /> is quite fine, as work items either end up blocking (which will create a<br /> new worker for other items), or they complete fairly quickly. But syzbot<br /> reports an issue where io-wq takes seemingly forever to exit, and with a<br /> bit of debugging, this turns out to be because it queues a bunch of big<br /> (2GB - 4096b) reads with a /dev/msr* file. Since this file type doesn&amp;#39;t<br /> support -&gt;read_iter(), loop_rw_iter() ends up handling them. Each read<br /> returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of<br /> these pending, processing the whole chain can take a long time. Easily<br /> longer than the syzbot uninterruptible sleep timeout of 140 seconds.<br /> This then triggers a complaint off the io-wq exit path:<br /> <br /> INFO: task syz.4.135:6326 blocked for more than 143 seconds.<br /> Not tainted syzkaller #0<br /> Blocked by coredump.<br /> "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 task_flags:0x400548 flags:0x00080000<br /> Call Trace:<br /> <br /> context_switch kernel/sched/core.c:5256 [inline]<br /> __schedule+0x1139/0x6150 kernel/sched/core.c:6863<br /> __schedule_loop kernel/sched/core.c:6945 [inline]<br /> schedule+0xe7/0x3a0 kernel/sched/core.c:6960<br /> schedule_timeout+0x257/0x290 kernel/time/sleep_timeout.c:75<br /> do_wait_for_common kernel/sched/completion.c:100 [inline]<br /> __wait_for_common+0x2fc/0x4e0 kernel/sched/completion.c:121<br /> io_wq_exit_workers io_uring/io-wq.c:1328 [inline]<br /> io_wq_put_and_exit+0x271/0x8a0 io_uring/io-wq.c:1356<br /> io_uring_clean_tctx+0x10d/0x190 io_uring/tctx.c:203<br /> io_uring_cancel_generic+0x69c/0x9a0 io_uring/cancel.c:651<br /> io_uring_files_cancel include/linux/io_uring.h:19 [inline]<br /> do_exit+0x2ce/0x2bd0 kernel/exit.c:911<br /> do_group_exit+0xd3/0x2a0 kernel/exit.c:1112<br /> get_signal+0x2671/0x26d0 kernel/signal.c:3034<br /> arch_do_signal_or_restart+0x8f/0x7e0 arch/x86/kernel/signal.c:337<br /> __exit_to_user_mode_loop kernel/entry/common.c:41 [inline]<br /> exit_to_user_mode_loop+0x8c/0x540 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+0x4ee/0xf80 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7fa02738f749<br /> RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca<br /> RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749<br /> RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098<br /> RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98<br /> <br /> There&amp;#39;s really nothing wrong here, outside of processing these reads<br /> will take a LONG time. However, we can speed up the exit by checking the<br /> IO_WQ_BIT_EXIT inside the io_worker_handle_work() loop, as syzbot will<br /> exit the ring after queueing up all of these reads. Then once the first<br /> item is processed, io-wq will simply cancel the rest. That should avoid<br /> syzbot running into this complaint again.

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.

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 /> 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.