Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: avoid buffer overflow attach in smu_sys_set_pp_table()<br /> <br /> It malicious user provides a small pptable through sysfs and then<br /> a bigger pptable, it may cause buffer overflow attack in function<br /> smu_sys_set_pp_table().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: rockchip: rkcanfd_handle_rx_fifo_overflow_int(): bail out if skb cannot be allocated<br /> <br /> Fix NULL pointer check in rkcanfd_handle_rx_fifo_overflow_int() to<br /> bail out if skb cannot be allocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: ctucanfd: handle skb allocation failure<br /> <br /> If skb allocation fails, the pointer to struct can_frame is NULL. This<br /> is actually handled everywhere inside ctucan_err_interrupt() except for<br /> the only place.<br /> <br /> Add the missed NULL check.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE static<br /> analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Reject Hyper-V&amp;#39;s SEND_IPI hypercalls if local APIC isn&amp;#39;t in-kernel<br /> <br /> Advertise support for Hyper-V&amp;#39;s SEND_IPI and SEND_IPI_EX hypercalls if and<br /> only if the local API is emulated/virtualized by KVM, and explicitly reject<br /> said hypercalls if the local APIC is emulated in userspace, i.e. don&amp;#39;t rely<br /> on userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.<br /> <br /> Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference if<br /> Hyper-V enlightenments are exposed to the guest without an in-kernel local<br /> APIC:<br /> <br /> dump_stack+0xbe/0xfd<br /> __kasan_report.cold+0x34/0x84<br /> kasan_report+0x3a/0x50<br /> __apic_accept_irq+0x3a/0x5c0<br /> kvm_hv_send_ipi.isra.0+0x34e/0x820<br /> kvm_hv_hypercall+0x8d9/0x9d0<br /> kvm_emulate_hypercall+0x506/0x7e0<br /> __vmx_handle_exit+0x283/0xb60<br /> vmx_handle_exit+0x1d/0xd0<br /> vcpu_enter_guest+0x16b0/0x24c0<br /> vcpu_run+0xc0/0x550<br /> kvm_arch_vcpu_ioctl_run+0x170/0x6d0<br /> kvm_vcpu_ioctl+0x413/0xb20<br /> __se_sys_ioctl+0x111/0x160<br /> do_syscal1_64+0x30/0x40<br /> entry_SYSCALL_64_after_hwframe+0x67/0xd1<br /> <br /> Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode<br /> can&amp;#39;t be modified after vCPUs are created, i.e. if one vCPU has an<br /> in-kernel local APIC, then all vCPUs have an in-kernel local APIC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ndisc: use RCU protection in ndisc_alloc_skb()<br /> <br /> ndisc_alloc_skb() can be called without RTNL or RCU being held.<br /> <br /> Add RCU protection to avoid possible UAF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: use RCU protection in ip6_default_advmss()<br /> <br /> ip6_default_advmss() needs rcu protection to make<br /> sure the net structure it reads does not disappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv4: use RCU protection in __ip_rt_update_pmtu()<br /> <br /> __ip_rt_update_pmtu() must use RCU protection to make<br /> sure the net structure it reads does not disappear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context<br /> <br /> The following bug report happened with a PREEMPT_RT kernel:<br /> <br /> BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 0, expected: 0<br /> get_random_u32+0x4f/0x110<br /> clocksource_verify_choose_cpus+0xab/0x1a0<br /> clocksource_verify_percpu.part.0+0x6b/0x330<br /> clocksource_watchdog_kthread+0x193/0x1a0<br /> <br /> It is due to the fact that clocksource_verify_choose_cpus() is invoked with<br /> preemption disabled. This function invokes get_random_u32() to obtain<br /> random numbers for choosing CPUs. The batched_entropy_32 local lock and/or<br /> the base_crng.lock spinlock in driver/char/random.c will be acquired during<br /> the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot<br /> be acquired in atomic context.<br /> <br /> Fix this problem by using migrate_disable() to allow smp_processor_id() to<br /> be reliably used without introducing atomic context. preempt_disable() is<br /> then called after clocksource_verify_choose_cpus() but before the<br /> clocksource measurement is being run to avoid introducing unexpected<br /> latency.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> partitions: mac: fix handling of bogus partition table<br /> <br /> Fix several issues in partition probing:<br /> <br /> - The bailout for a bad partoffset must use put_dev_sector(), since the<br /> preceding read_part_sector() succeeded.<br /> - If the partition table claims a silly sector size like 0xfff bytes<br /> (which results in partition table entries straddling sector boundaries),<br /> bail out instead of accessing out-of-bounds memory.<br /> - We must not assume that the partition table contains proper NUL<br /> termination - use strnlen() and strncmp() instead of strlen() and<br /> strcmp().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels<br /> <br /> Some lwtunnels have a dst cache for post-transformation dst.<br /> If the packet destination did not change we may end up recording<br /> a reference to the lwtunnel in its own cache, and the lwtunnel<br /> state will never be freed.<br /> <br /> Discovered by the ioam6.sh test, kmemleak was recently fixed<br /> to catch per-cpu memory leaks. I&amp;#39;m not sure if rpl and seg6<br /> can actually hit this, but in principle I don&amp;#39;t see why not.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix incorrect autogroup migration detection<br /> <br /> scx_move_task() is called from sched_move_task() and tells the BPF scheduler<br /> that cgroup migration is being committed. sched_move_task() is used by both<br /> cgroup and autogroup migrations and scx_move_task() tried to filter out<br /> autogroup migrations by testing the destination cgroup and PF_EXITING but<br /> this is not enough. In fact, without explicitly tagging the thread which is<br /> doing the cgroup migration, there is no good way to tell apart<br /> scx_move_task() invocations for racing migration to the root cgroup and an<br /> autogroup migration.<br /> <br /> This led to scx_move_task() incorrectly ignoring a migration from non-root<br /> cgroup to an autogroup of the root cgroup triggering the following warning:<br /> <br /> WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340<br /> ...<br /> Call Trace:<br /> <br /> cgroup_migrate_execute+0x5b1/0x700<br /> cgroup_attach_task+0x296/0x400<br /> __cgroup_procs_write+0x128/0x140<br /> cgroup_procs_write+0x17/0x30<br /> kernfs_fop_write_iter+0x141/0x1f0<br /> vfs_write+0x31d/0x4a0<br /> __x64_sys_write+0x72/0xf0<br /> do_syscall_64+0x82/0x160<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Fix it by adding an argument to sched_move_task() that indicates whether the<br /> moving is for a cgroup or autogroup migration. After the change,<br /> scx_move_task() is called only for cgroup migrations and renamed to<br /> scx_cgroup_move_task().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: vmclock: Add .owner to vmclock_miscdev_fops<br /> <br /> Without the .owner field, the module can be unloaded while /dev/vmclock0<br /> is open, leading to an oops.