Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Revert to requiring CAP_SYS_ADMIN for uprobes<br /> <br /> Jann reports that uprobes can be used destructively when used in the<br /> middle of an instruction. The kernel only verifies there is a valid<br /> instruction at the requested offset, but due to variable instruction<br /> length cannot determine if this is an instruction as seen by the<br /> intended execution stream.<br /> <br /> Additionally, Mark Rutland notes that on architectures that mix data<br /> in the text segment (like arm64), a similar things can be done if the<br /> data word is &amp;#39;mistaken&amp;#39; for an instruction.<br /> <br /> As such, require CAP_SYS_ADMIN for uprobes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: Fix transport_{g2h,h2g} TOCTOU<br /> <br /> vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.<br /> transport_{g2h,h2g} may become NULL after the NULL check.<br /> <br /> Introduce vsock_transport_local_cid() to protect from a potential<br /> null-ptr-deref.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> RIP: 0010:vsock_find_cid+0x47/0x90<br /> Call Trace:<br /> __vsock_bind+0x4b2/0x720<br /> vsock_bind+0x90/0xe0<br /> __sys_bind+0x14d/0x1e0<br /> __x64_sys_bind+0x6e/0xc0<br /> do_syscall_64+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0<br /> Call Trace:<br /> __x64_sys_ioctl+0x12d/0x190<br /> do_syscall_64+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Correct signedness in skb remaining space calculation<br /> <br /> Syzkaller reported a bug [1] where sk-&gt;sk_forward_alloc can overflow.<br /> <br /> When we send data, if an skb exists at the tail of the write queue, the<br /> kernel will attempt to append the new data to that skb. However, the code<br /> that checks for available space in the skb is flawed:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> copy = size_goal - skb-&gt;len<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> The types of the variables involved are:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> copy: ssize_t (s64 on 64-bit systems)<br /> size_goal: int<br /> skb-&gt;len: unsigned int<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> Due to C&amp;#39;s type promotion rules, the signed size_goal is converted to an<br /> unsigned int to match skb-&gt;len before the subtraction. The result is an<br /> unsigned int.<br /> <br /> When this unsigned int result is then assigned to the s64 copy variable,<br /> it is zero-extended, preserving its non-negative value. Consequently, copy<br /> is always &gt;= 0.<br /> <br /> Assume we are sending 2GB of data and size_goal has been adjusted to a<br /> value smaller than skb-&gt;len. The subtraction will result in copy holding a<br /> very large positive integer. In the subsequent logic, this large value is<br /> used to update sk-&gt;sk_forward_alloc, which can easily cause it to overflow.<br /> <br /> The syzkaller reproducer uses TCP_REPAIR to reliably create this<br /> condition. However, this can also occur in real-world scenarios. The<br /> tcp_bound_to_half_wnd() function can also reduce size_goal to a small<br /> value. This would cause the subsequent tcp_wmem_schedule() to set<br /> sk-&gt;sk_forward_alloc to a value close to INT_MAX. Further memory<br /> allocation requests would then cause sk_forward_alloc to wrap around and<br /> become negative.<br /> <br /> [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()<br /> <br /> The "intf" list iterator is an invalid pointer if the correct<br /> "intf-&gt;intf_num" is not found. Calling atomic_dec(&amp;intf-&gt;nr_users) on<br /> and invalid pointer will lead to memory corruption.<br /> <br /> We don&amp;#39;t really need to call atomic_dec() if we haven&amp;#39;t called<br /> atomic_add_return() so update the if (intf-&gt;in_shutdown) path as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Abort __tc_modify_qdisc if parent class does not exist<br /> <br /> Lion&amp;#39;s patch [1] revealed an ancient bug in the qdisc API.<br /> Whenever a user creates/modifies a qdisc specifying as a parent another<br /> qdisc, the qdisc API will, during grafting, detect that the user is<br /> not trying to attach to a class and reject. However grafting is<br /> performed after qdisc_create (and thus the qdiscs&amp;#39; init callback) is<br /> executed. In qdiscs that eventually call qdisc_tree_reduce_backlog<br /> during init or change (such as fq, hhf, choke, etc), an issue<br /> arises. For example, executing the following commands:<br /> <br /> sudo tc qdisc add dev lo root handle a: htb default 2<br /> sudo tc qdisc add dev lo parent a: handle beef fq<br /> <br /> Qdiscs such as fq, hhf, choke, etc unconditionally invoke<br /> qdisc_tree_reduce_backlog() in their control path init() or change() which<br /> then causes a failure to find the child class; however, that does not stop<br /> the unconditional invocation of the assumed child qdisc&amp;#39;s qlen_notify with<br /> a null class. All these qdiscs make the assumption that class is non-null.<br /> <br /> The solution is ensure that qdisc_leaf() which looks up the parent<br /> class, and is invoked prior to qdisc_create(), should return failure on<br /> not finding the class.<br /> In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the<br /> parentid doesn&amp;#39;t correspond to a class, so that we can detect it<br /> earlier on and abort before qdisc_create is called.<br /> <br /> [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: Fix NULL pointer dereference in vcc_sendmsg()<br /> <br /> atmarpd_dev_ops does not implement the send method, which may cause crash<br /> as bellow.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: Oops: 0010 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246<br /> RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000<br /> RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000<br /> RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287<br /> R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00<br /> R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88<br /> FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x219/0x270 net/socket.c:727<br /> ____sys_sendmsg+0x52d/0x830 net/socket.c:2566<br /> ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620<br /> __sys_sendmmsg+0x227/0x430 net/socket.c:2709<br /> __do_sys_sendmmsg net/socket.c:2736 [inline]<br /> __se_sys_sendmmsg net/socket.c:2733 [inline]<br /> __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: Fix infinite recursive call of clip_push().<br /> <br /> syzbot reported the splat below. [0]<br /> <br /> This happens if we call ioctl(ATMARP_MKIP) more than once.<br /> <br /> During the first call, clip_mkip() sets clip_push() to vcc-&gt;push(),<br /> and the second call copies it to clip_vcc-&gt;old_push().<br /> <br /> Later, when the socket is close()d, vcc_destroy_socket() passes<br /> NULL skb to clip_push(), which calls clip_vcc-&gt;old_push(),<br /> triggering the infinite recursion.<br /> <br /> Let&amp;#39;s prevent the second ioctl(ATMARP_MKIP) by checking<br /> vcc-&gt;user_back, which is allocated by the first call as clip_vcc.<br /> <br /> Note also that we use lock_sock() to prevent racy calls.<br /> <br /> [0]:<br /> BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)<br /> Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191<br /> Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00<br /> RSP: 0018:ffffc9000d670000 EFLAGS: 00010246<br /> RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000<br /> RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e<br /> R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300<br /> R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578<br /> FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> ...<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> vcc_destroy_socket net/atm/common.c:183 [inline]<br /> vcc_release+0x157/0x460 net/atm/common.c:205<br /> __sock_release net/socket.c:647 [inline]<br /> sock_close+0xc0/0x240 net/socket.c:1391<br /> __fput+0x449/0xa70 fs/file_table.c:465<br /> task_work_run+0x1d1/0x260 kernel/task_work.c:227<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114<br /> exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline]<br /> do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff31c98e929<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4<br /> RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929<br /> RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003<br /> RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f<br /> R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c<br /> R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090<br /> <br /> Modules linked in:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: Fix potential null-ptr-deref in to_atmarpd().<br /> <br /> atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip<br /> causes unregister hang").<br /> <br /> However, it is not enough because to_atmarpd() is called without RTNL,<br /> especially clip_neigh_solicit() / neigh_ops-&gt;solicit() is unsleepable.<br /> <br /> Also, there is no RTNL dependency around atmarpd.<br /> <br /> Let&amp;#39;s use a private mutex and RCU to protect access to atmarpd in<br /> to_atmarpd().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: Fix transport_* TOCTOU<br /> <br /> Transport assignment may race with module unload. Protect new_transport<br /> from becoming a stale pointer.<br /> <br /> This also takes care of an insecure call in vsock_use_local_transport();<br /> add a lockdep assert.<br /> <br /> BUG: unable to handle page fault for address: fffffbfff8056000<br /> Oops: Oops: 0000 [#1] SMP KASAN<br /> RIP: 0010:vsock_assign_transport+0x366/0x600<br /> Call Trace:<br /> vsock_connect+0x59c/0xc40<br /> __sys_connect+0xe8/0x100<br /> __x64_sys_connect+0x6e/0xc0<br /> do_syscall_64+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight<br /> <br /> Reject migration of SEV{-ES} state if either the source or destination VM<br /> is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the<br /> section between incrementing created_vcpus and online_vcpus. The bulk of<br /> vCPU creation runs _outside_ of kvm-&gt;lock to allow creating multiple vCPUs<br /> in parallel, and so sev_info.es_active can get toggled from false=&gt;true in<br /> the destination VM after (or during) svm_vcpu_create(), resulting in an<br /> SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.<br /> <br /> The issue manifests most visibly as a crash when trying to free a vCPU&amp;#39;s<br /> NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.<br /> <br /> BUG: unable to handle page fault for address: ffffebde00000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE<br /> Tainted: [U]=USER, [O]=OOT_MODULE<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024<br /> RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]<br /> RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]<br /> RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]<br /> RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]<br /> RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067<br /> Code: f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0<br /> RSP: 0018:ffff8984551978d0 EFLAGS: 00010246<br /> RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98<br /> RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000<br /> RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000<br /> R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000<br /> R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000<br /> FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0<br /> DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169<br /> svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515<br /> kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396<br /> kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]<br /> kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490<br /> kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895<br /> kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310<br /> kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369<br /> __fput+0x3e4/0x9e0 fs/file_table.c:465<br /> task_work_run+0x1a9/0x220 kernel/task_work.c:227<br /> exit_task_work include/linux/task_work.h:40 [inline]<br /> do_exit+0x7f0/0x25b0 kernel/exit.c:953<br /> do_group_exit+0x203/0x2d0 kernel/exit.c:1102<br /> get_signal+0x1357/0x1480 kernel/signal.c:3034<br /> arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337<br /> exit_to_user_mode_loop kernel/entry/common.c:111 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218<br /> do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f87a898e969<br /> <br /> Modules linked in: gq(O)<br /> gsmi: Log Shutdown Reason 0x03<br /> CR2: ffffebde00000000<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Deliberately don&amp;#39;t check for a NULL VMSA when freeing the vCPU, as crashing<br /> the host is likely desirable due to the VMSA being consumed by hardware.<br /> E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a<br /> bogus VMSA page. Accessing P<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp()<br /> <br /> Use pr_warn() instead of dev_warn() when &amp;#39;pdev&amp;#39; is NULL to avoid a<br /> potential NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_serial: Fix race condition in TTY wakeup<br /> <br /> A race condition occurs when gs_start_io() calls either gs_start_rx() or<br /> gs_start_tx(), as those functions briefly drop the port_lock for<br /> usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear<br /> port.tty and port_usb, respectively.<br /> <br /> Use the null-safe TTY Port helper function to wake up TTY.<br /> <br /> Example<br /> CPU1: CPU2:<br /> gserial_connect() // lock<br /> gs_close() // await lock<br /> gs_start_rx() // unlock<br /> usb_ep_queue()<br /> gs_close() // lock, reset port.tty and unlock<br /> gs_start_rx() // lock<br /> tty_wakeup() // NPE