Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: scsi_transport_sas: Fix error handling in sas_phy_add()<br /> <br /> If transport_add_device() fails in sas_phy_add(), the kernel will crash<br /> trying to delete the device in transport_remove_device() called from<br /> sas_remove_host().<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108<br /> CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : device_del+0x54/0x3d0<br /> lr : device_del+0x37c/0x3d0<br /> Call trace:<br /> device_del+0x54/0x3d0<br /> attribute_container_class_device_del+0x28/0x38<br /> transport_remove_classdev+0x6c/0x80<br /> attribute_container_device_trigger+0x108/0x110<br /> transport_remove_device+0x28/0x38<br /> sas_phy_delete+0x30/0x60 [scsi_transport_sas]<br /> do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas]<br /> device_for_each_child+0x68/0xb0<br /> sas_remove_children+0x40/0x50 [scsi_transport_sas]<br /> sas_remove_host+0x20/0x38 [scsi_transport_sas]<br /> hisi_sas_remove+0x40/0x68 [hisi_sas_main]<br /> hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw]<br /> platform_remove+0x2c/0x60<br /> <br /> Fix this by checking and handling return value of transport_add_device()<br /> in sas_phy_add().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()<br /> <br /> We got a syzkaller problem because of aarch64 alignment fault<br /> if KFENCE enabled. When the size from user bpf program is an odd<br /> number, like 399, 407, etc, it will cause the struct skb_shared_info&amp;#39;s<br /> unaligned access. As seen below:<br /> <br /> BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032<br /> <br /> Use-after-free read at 0xffff6254fffac077 (in kfence-#213):<br /> __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline]<br /> arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline]<br /> arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline]<br /> atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline]<br /> __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032<br /> skb_clone+0xf4/0x214 net/core/skbuff.c:1481<br /> ____bpf_clone_redirect net/core/filter.c:2433 [inline]<br /> bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420<br /> bpf_prog_d3839dd9068ceb51+0x80/0x330<br /> bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline]<br /> bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53<br /> bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594<br /> bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]<br /> __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]<br /> __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381<br /> <br /> kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512<br /> <br /> allocated by task 15074 on cpu 0 at 1342.585390s:<br /> kmalloc include/linux/slab.h:568 [inline]<br /> kzalloc include/linux/slab.h:675 [inline]<br /> bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191<br /> bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512<br /> bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline]<br /> __do_sys_bpf kernel/bpf/syscall.c:4441 [inline]<br /> __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381<br /> __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381<br /> <br /> To fix the problem, we adjust @size so that (@size + @hearoom) is a<br /> multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info<br /> is aligned to a cache line.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: core: Fix use-after-free in snd_soc_exit()<br /> <br /> KASAN reports a use-after-free:<br /> <br /> BUG: KASAN: use-after-free in device_del+0xb5b/0xc60<br /> Read of size 8 at addr ffff888008655050 by task rmmod/387<br /> CPU: 2 PID: 387 Comm: rmmod<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x79/0x9a<br /> print_report+0x17f/0x47b<br /> kasan_report+0xbb/0xf0<br /> device_del+0xb5b/0xc60<br /> platform_device_del.part.0+0x24/0x200<br /> platform_device_unregister+0x2e/0x40<br /> snd_soc_exit+0xa/0x22 [snd_soc_core]<br /> __do_sys_delete_module.constprop.0+0x34f/0x5b0<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> ...<br /> <br /> <br /> It&amp;#39;s bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,<br /> but its ret is ignored, which makes soc_dummy_dev unregistered twice.<br /> <br /> snd_soc_init()<br /> snd_soc_util_init()<br /> platform_device_register_simple(soc_dummy_dev)<br /> platform_driver_register() # fail<br /> platform_device_unregister(soc_dummy_dev)<br /> platform_driver_register() # success<br /> ...<br /> snd_soc_exit()<br /> snd_soc_util_exit()<br /> # soc_dummy_dev will be unregistered for second time<br /> <br /> To fix it, handle error and stop snd_soc_init() when util_init() fail.<br /> Also clean debugfs when util_init() or driver_register() fail.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: dev: fix skb drop check<br /> <br /> In commit a6d190f8c767 ("can: skb: drop tx skb if in listen only<br /> mode") the priv-&gt;ctrlmode element is read even on virtual CAN<br /> interfaces that do not create the struct can_priv at startup. This<br /> out-of-bounds read may lead to CAN frame drops for virtual CAN<br /> interfaces like vcan and vxcan.<br /> <br /> This patch mainly reverts the original commit and adds a new helper<br /> for CAN interface drivers that provide the required information in<br /> struct can_priv.<br /> <br /> [mkl: patch pch_can, too]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> siox: fix possible memory leak in siox_device_add()<br /> <br /> If device_register() returns error in siox_device_add(),<br /> the name allocated by dev_set_name() need be freed. As<br /> comment of device_register() says, it should use put_device()<br /> to give up the reference in the error path. So fix this<br /> by calling put_device(), then the name can be freed in<br /> kobject_cleanup(), and sdevice is freed in siox_device_release(),<br /> set it to null in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: clear out_curr if all frag chunks of current msg are pruned<br /> <br /> A crash was reported by Zhen Chen:<br /> <br /> list_del corruption, ffffa035ddf01c18-&gt;next is NULL<br /> WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0<br /> RIP: 0010:__list_del_entry_valid+0x59/0xe0<br /> Call Trace:<br /> sctp_sched_dequeue_common+0x17/0x70 [sctp]<br /> sctp_sched_fcfs_dequeue+0x37/0x50 [sctp]<br /> sctp_outq_flush_data+0x85/0x360 [sctp]<br /> sctp_outq_uncork+0x77/0xa0 [sctp]<br /> sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp]<br /> sctp_side_effects+0x37/0xe0 [sctp]<br /> sctp_do_sm+0xd0/0x230 [sctp]<br /> sctp_primitive_SEND+0x2f/0x40 [sctp]<br /> sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp]<br /> sctp_sendmsg+0x3d5/0x440 [sctp]<br /> sock_sendmsg+0x5b/0x70<br /> <br /> and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream<br /> out_curr outq while this outq was empty.<br /> <br /> Normally stream-&gt;out_curr must be set to NULL once all frag chunks of<br /> current msg are dequeued, as we can see in sctp_sched_dequeue_done().<br /> However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue,<br /> sctp_sched_dequeue_done() is not called to do this.<br /> <br /> This patch is to fix it by simply setting out_curr to NULL when the<br /> last frag chunk of current msg is dequeued from out_curr stream in<br /> sctp_prsctp_prune_unsent().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: imx: Add missing .thaw_noirq hook<br /> <br /> The following warning is seen with non-console UART instance when<br /> system hibernates.<br /> <br /> [ 37.371969] ------------[ cut here ]------------<br /> [ 37.376599] uart3_root_clk already disabled<br /> [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0<br /> ...<br /> [ 37.506986] Call trace:<br /> [ 37.509432] clk_core_disable+0xa4/0xb0<br /> [ 37.513270] clk_disable+0x34/0x50<br /> [ 37.516672] imx_uart_thaw+0x38/0x5c<br /> [ 37.520250] platform_pm_thaw+0x30/0x6c<br /> [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4<br /> [ 37.528972] device_resume+0x7c/0x160<br /> [ 37.532633] dpm_resume+0xe8/0x230<br /> [ 37.536036] hibernation_snapshot+0x288/0x430<br /> [ 37.540397] hibernate+0x10c/0x2e0<br /> [ 37.543798] state_store+0xc4/0xd0<br /> [ 37.547203] kobj_attr_store+0x1c/0x30<br /> [ 37.550953] sysfs_kf_write+0x48/0x60<br /> [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac<br /> [ 37.559063] new_sync_write+0xe8/0x184<br /> [ 37.562812] vfs_write+0x230/0x290<br /> [ 37.566214] ksys_write+0x68/0xf4<br /> [ 37.569529] __arm64_sys_write+0x20/0x2c<br /> [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0<br /> [ 37.578156] do_el0_svc+0x11c/0x150<br /> [ 37.581648] el0_svc+0x30/0x140<br /> [ 37.584792] el0t_64_sync_handler+0xe8/0xf0<br /> [ 37.588976] el0t_64_sync+0x1a0/0x1a4<br /> [ 37.592639] ---[ end trace 56e22eec54676d75 ]---<br /> <br /> On hibernating, pm core calls into related hooks in sequence like:<br /> <br /> .freeze<br /> .freeze_noirq<br /> .thaw_noirq<br /> .thaw<br /> <br /> With .thaw_noirq hook being absent, the clock will be disabled in a<br /> unbalanced call which results the warning above.<br /> <br /> imx_uart_freeze()<br /> clk_prepare_enable()<br /> imx_uart_suspend_noirq()<br /> clk_disable()<br /> imx_uart_thaw<br /> clk_disable_unprepare()<br /> <br /> Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have<br /> the call sequence corrected as below and thus fix the warning.<br /> <br /> imx_uart_freeze()<br /> clk_prepare_enable()<br /> imx_uart_suspend_noirq()<br /> clk_disable()<br /> imx_uart_resume_noirq()<br /> clk_enable()<br /> imx_uart_thaw<br /> clk_disable_unprepare()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map<br /> <br /> Here is the BUG report by KASAN about null pointer dereference:<br /> <br /> BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50<br /> Read of size 1 at addr 0000000000000000 by task python3/2640<br /> Call Trace:<br /> strcmp<br /> __of_find_property<br /> of_find_property<br /> pinctrl_dt_to_map<br /> <br /> kasprintf() would return NULL pointer when kmalloc() fail to allocate.<br /> So directly return ENOMEM, if kasprintf() return NULL pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: initialize device&amp;#39;s zone info for seeding<br /> <br /> When performing seeding on a zoned filesystem it is necessary to<br /> initialize each zoned device&amp;#39;s btrfs_zoned_device_info structure,<br /> otherwise mounting the filesystem will cause a NULL pointer dereference.<br /> <br /> This was uncovered by fstests&amp;#39; testcase btrfs/163.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/drv: Fix potential memory leak in drm_dev_init()<br /> <br /> drm_dev_init() will add drm_dev_init_release() as a callback. When<br /> drmm_add_action() failed, the release function won&amp;#39;t be added. As the<br /> result, the ref cnt added by device_get() in drm_dev_init() won&amp;#39;t be put<br /> by drm_dev_init_release(), which leads to the memleak. Use<br /> drmm_add_action_or_reset() instead of drmm_add_action() to prevent<br /> memleak.<br /> <br /> unreferenced object 0xffff88810bc0c800 (size 2048):<br /> comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s)<br /> hex dump (first 32 bytes):<br /> e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................<br /> 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/scheduler: fix fence ref counting<br /> <br /> We leaked dependency fences when processes were beeing killed.<br /> <br /> Additional to that grab a reference to the last scheduled fence.