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 /> batman-adv: fix panic during interface removal<br /> <br /> Reference counting is used to ensure that<br /> batadv_hardif_neigh_node and batadv_hard_iface<br /> are not freed before/during<br /> batadv_v_elp_throughput_metric_update work is<br /> finished.<br /> <br /> But there isn&amp;#39;t a guarantee that the hard if will<br /> remain associated with a soft interface up until<br /> the work is finished.<br /> <br /> This fixes a crash triggered by reboot that looks<br /> like this:<br /> <br /> Call trace:<br /> batadv_v_mesh_free+0xd0/0x4dc [batman_adv]<br /> batadv_v_elp_throughput_metric_update+0x1c/0xa4<br /> process_one_work+0x178/0x398<br /> worker_thread+0x2e8/0x4d0<br /> kthread+0xd8/0xdc<br /> ret_from_fork+0x10/0x20<br /> <br /> (the batadv_v_mesh_free call is misleading,<br /> and does not actually happen)<br /> <br /> I was able to make the issue happen more reliably<br /> by changing hardif_neigh-&gt;bat_v.metric_work work<br /> to be delayed work. This allowed me to track down<br /> and confirm the fix.<br /> <br /> [sven@narfation.org: prevent entering batadv_v_elp_get_throughput without<br /> soft_iface]

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 /> USB: hub: Ignore non-compliant devices with too many configs or interfaces<br /> <br /> Robert Morris created a test program which can cause<br /> usb_hub_to_struct_hub() to dereference a NULL or inappropriate<br /> pointer:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTI<br /> CPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14<br /> Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110<br /> ...<br /> Call Trace:<br /> <br /> ? die_addr+0x31/0x80<br /> ? exc_general_protection+0x1b4/0x3c0<br /> ? asm_exc_general_protection+0x26/0x30<br /> ? usb_hub_adjust_deviceremovable+0x78/0x110<br /> hub_probe+0x7c7/0xab0<br /> usb_probe_interface+0x14b/0x350<br /> really_probe+0xd0/0x2d0<br /> ? __pfx___device_attach_driver+0x10/0x10<br /> __driver_probe_device+0x6e/0x110<br /> driver_probe_device+0x1a/0x90<br /> __device_attach_driver+0x7e/0xc0<br /> bus_for_each_drv+0x7f/0xd0<br /> __device_attach+0xaa/0x1a0<br /> bus_probe_device+0x8b/0xa0<br /> device_add+0x62e/0x810<br /> usb_set_configuration+0x65d/0x990<br /> usb_generic_driver_probe+0x4b/0x70<br /> usb_probe_device+0x36/0xd0<br /> <br /> The cause of this error is that the device has two interfaces, and the<br /> hub driver binds to interface 1 instead of interface 0, which is where<br /> usb_hub_to_struct_hub() looks.<br /> <br /> We can prevent the problem from occurring by refusing to accept hub<br /> devices that violate the USB spec by having more than one<br /> configuration or interface.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix potential memory leak in iopf_queue_remove_device()<br /> <br /> The iopf_queue_remove_device() helper removes a device from the per-iommu<br /> iopf queue when PRI is disabled on the device. It responds to all<br /> outstanding iopf&amp;#39;s with an IOMMU_PAGE_RESP_INVALID code and detaches the<br /> device from the queue.<br /> <br /> However, it fails to release the group structure that represents a group<br /> of iopf&amp;#39;s awaiting for a response after responding to the hardware. This<br /> can cause a memory leak if iopf_queue_remove_device() is called with<br /> pending iopf&amp;#39;s.<br /> <br /> Fix it by calling iopf_free_group() after the iopf group is responded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: etas_es58x: fix potential NULL pointer dereference on udev-&gt;serial<br /> <br /> The driver assumed that es58x_dev-&gt;udev-&gt;serial could never be NULL.<br /> While this is true on commercially available devices, an attacker<br /> could spoof the device identity providing a NULL USB serial number.<br /> That would trigger a NULL pointer dereference.<br /> <br /> Add a check on es58x_dev-&gt;udev-&gt;serial before accessing it.

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.