Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> coresight: trbe: remove cpuhp instance node before remove cpuhp state<br /> <br /> cpuhp_state_add_instance() and cpuhp_state_remove_instance() should<br /> be used in pairs. Or there will lead to the warn on<br /> cpuhp_remove_multi_state() since the cpuhp_step list is not empty.<br /> <br /> The following is the error log with &amp;#39;rmmod coresight-trbe&amp;#39;:<br /> Error: Removing state 215 which has instances left.<br /> Call trace:<br /> __cpuhp_remove_state_cpuslocked+0x144/0x160<br /> __cpuhp_remove_state+0xac/0x100<br /> arm_trbe_device_remove+0x2c/0x60 [coresight_trbe]<br /> platform_remove+0x34/0x70<br /> device_remove+0x54/0x90<br /> device_release_driver_internal+0x1e4/0x250<br /> driver_detach+0x5c/0xb0<br /> bus_remove_driver+0x64/0xc0<br /> driver_unregister+0x3c/0x70<br /> platform_driver_unregister+0x20/0x30<br /> arm_trbe_exit+0x1c/0x658 [coresight_trbe]<br /> __arm64_sys_delete_module+0x1ac/0x24c<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0x58/0x1a0<br /> do_el0_svc+0x38/0xd0<br /> el0_svc+0x2c/0xc0<br /> el0t_64_sync_handler+0x1ac/0x1b0<br /> el0t_64_sync+0x19c/0x1a0<br /> ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sof_es8336: fix possible use-after-free in sof_es8336_remove()<br /> <br /> sof_es8336_remove() calls cancel_delayed_work(). However, that<br /> function does not wait until the work function finishes. This<br /> means that the callback function may still be running after<br /> the driver&amp;#39;s remove function has finished, which would result<br /> in a use-after-free.<br /> <br /> Fix by calling cancel_delayed_work_sync(), which ensures that<br /> the work is properly cancelled, no longer running, and unable<br /> to re-schedule itself.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix potential out of bound read in ext4_fc_replay_scan()<br /> <br /> For scan loop must ensure that at least EXT4_FC_TAG_BASE_LEN space. If remain<br /> space less than EXT4_FC_TAG_BASE_LEN which will lead to out of bound read<br /> when mounting corrupt file system image.<br /> ADD_RANGE/HEAD/TAIL is needed to add extra check when do journal scan, as this<br /> three tags will read data during scan, tag length couldn&amp;#39;t less than data length<br /> which will read.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/cio: fix out-of-bounds access on cio_ignore free<br /> <br /> The channel-subsystem-driver scans for newly available devices whenever<br /> device-IDs are removed from the cio_ignore list using a command such as:<br /> <br /> echo free &gt;/proc/cio_ignore<br /> <br /> Since an I/O device scan might interfer with running I/Os, commit<br /> 172da89ed0ea ("s390/cio: avoid excessive path-verification requests")<br /> introduced an optimization to exclude online devices from the scan.<br /> <br /> The newly added check for online devices incorrectly assumes that<br /> an I/O-subchannel&amp;#39;s drvdata points to a struct io_subchannel_private.<br /> For devices that are bound to a non-default I/O subchannel driver, such<br /> as the vfio_ccw driver, this results in an out-of-bounds read access<br /> during each scan.<br /> <br /> Fix this by changing the scan logic to rely on a driver-independent<br /> online indication. For this we can use struct subchannel-&gt;config.ena,<br /> which is the driver&amp;#39;s requested subchannel-enabled state. Since I/Os<br /> can only be started on enabled subchannels, this matches the intent<br /> of the original optimization of not scanning devices where I/O might<br /> be running.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: qcom: Add checks for devm_kcalloc<br /> <br /> As the devm_kcalloc may return NULL, the return value needs to be checked<br /> to avoid NULL poineter dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ip6mr: fix UAF issue in ip6mr_sk_done() when addrconf_init_net() failed<br /> <br /> If the initialization fails in calling addrconf_init_net(), devconf_all is<br /> the pointer that has been released. Then ip6mr_sk_done() is called to<br /> release the net, accessing devconf-&gt;mc_forwarding directly causes invalid<br /> pointer access.<br /> <br /> The process is as follows:<br /> setup_net()<br /> ops_init()<br /> addrconf_init_net()<br /> all = kmemdup(...) ---&gt; alloc "all"<br /> ...<br /> net-&gt;ipv6.devconf_all = all;<br /> __addrconf_sysctl_register() ---&gt; failed<br /> ...<br /> kfree(all); ---&gt; ipv6.devconf_all invalid<br /> ...<br /> ops_exit_list()<br /> ...<br /> ip6mr_sk_done()<br /> devconf = net-&gt;ipv6.devconf_all;<br /> //devconf is invalid pointer<br /> if (!devconf || !atomic_read(&amp;devconf-&gt;mc_forwarding))<br /> <br /> The following is the Call Trace information:<br /> BUG: KASAN: use-after-free in ip6mr_sk_done+0x112/0x3a0<br /> Read of size 4 at addr ffff888075508e88 by task ip/14554<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8e/0xd1<br /> print_report+0x155/0x454<br /> kasan_report+0xba/0x1f0<br /> kasan_check_range+0x35/0x1b0<br /> ip6mr_sk_done+0x112/0x3a0<br /> rawv6_close+0x48/0x70<br /> inet_release+0x109/0x230<br /> inet6_release+0x4c/0x70<br /> sock_release+0x87/0x1b0<br /> igmp6_net_exit+0x6b/0x170<br /> ops_exit_list+0xb0/0x170<br /> setup_net+0x7ac/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f7963322547<br /> <br /> <br /> Allocated by task 14554:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0xa1/0xb0<br /> __kmalloc_node_track_caller+0x4a/0xb0<br /> kmemdup+0x28/0x60<br /> addrconf_init_net+0x1be/0x840<br /> ops_init+0xa5/0x410<br /> setup_net+0x5aa/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Freed by task 14554:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x155/0x1b0<br /> slab_free_freelist_hook+0x11b/0x220<br /> __kmem_cache_free+0xa4/0x360<br /> addrconf_init_net+0x623/0x840<br /> ops_init+0xa5/0x410<br /> setup_net+0x5aa/0xbd0<br /> copy_net_ns+0x2e6/0x6b0<br /> create_new_namespaces+0x382/0xa50<br /> unshare_nsproxy_namespaces+0xa6/0x1c0<br /> ksys_unshare+0x3a4/0x7e0<br /> __x64_sys_unshare+0x2d/0x40<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: Fix refcount leak in cxl_calc_capp_routing<br /> <br /> of_get_next_parent() returns a node pointer with refcount incremented,<br /> we should use of_node_put() on it when not need anymore.<br /> This function only calls of_node_put() in normal path,<br /> missing it in the error path.<br /> Add missing of_node_put() to avoid refcount leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: serial: jsm: fix some leaks in probe<br /> <br /> This error path needs to unwind instead of just returning directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: verify the expected usb_endpoints are present<br /> <br /> The bug arises when a USB device claims to be an ATH9K but doesn&amp;#39;t<br /> have the expected endpoints. (In this case there was an interrupt<br /> endpoint where the driver expected a bulk endpoint.) The kernel<br /> needs to be able to handle such devices without getting an internal error.<br /> <br /> usb 1-1: BOGUS urb xfer, pipe 3 != type 1<br /> WARNING: CPU: 3 PID: 500 at drivers/usb/core/urb.c:493 usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493<br /> Modules linked in:<br /> CPU: 3 PID: 500 Comm: kworker/3:2 Not tainted 5.10.135-syzkaller #0<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014<br /> Workqueue: events request_firmware_work_func<br /> RIP: 0010:usb_submit_urb+0xce2/0x1430 drivers/usb/core/urb.c:493<br /> Call Trace:<br /> ath9k_hif_usb_alloc_rx_urbs drivers/net/wireless/ath/ath9k/hif_usb.c:908 [inline]<br /> ath9k_hif_usb_alloc_urbs+0x75e/0x1010 drivers/net/wireless/ath/ath9k/hif_usb.c:1019<br /> ath9k_hif_usb_dev_init drivers/net/wireless/ath/ath9k/hif_usb.c:1109 [inline]<br /> ath9k_hif_usb_firmware_cb+0x142/0x530 drivers/net/wireless/ath/ath9k/hif_usb.c:1242<br /> request_firmware_work_func+0x12e/0x240 drivers/base/firmware_loader/main.c:1097<br /> process_one_work+0x9af/0x1600 kernel/workqueue.c:2279<br /> worker_thread+0x61d/0x12f0 kernel/workqueue.c:2425<br /> kthread+0x3b4/0x4a0 kernel/kthread.c:313<br /> ret_from_fork+0x22/0x30 arch/x86/entry/entry_64.S:299<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> slimbus: qcom-ngd: cleanup in probe error path<br /> <br /> Add proper error path in probe() to cleanup resources previously<br /> acquired/allocated to fix warnings visible during probe deferral:<br /> <br /> notifier callback qcom_slim_ngd_ssr_notify already registered<br /> WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90<br /> Modules linked in:<br /> CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380<br /> Call trace:<br /> notifier_chain_register+0x5c/0x90<br /> srcu_notifier_chain_register+0x44/0x90<br /> qcom_register_ssr_notifier+0x38/0x4c<br /> qcom_slim_ngd_ctrl_probe+0xd8/0x400<br /> platform_probe+0x6c/0xe0<br /> really_probe+0xbc/0x2d4<br /> __driver_probe_device+0x78/0xe0<br /> driver_probe_device+0x3c/0x12c<br /> __device_attach_driver+0xb8/0x120<br /> bus_for_each_drv+0x78/0xd0<br /> __device_attach+0xa8/0x1c0<br /> device_initial_probe+0x18/0x24<br /> bus_probe_device+0xa0/0xac<br /> deferred_probe_work_func+0x88/0xc0<br /> process_one_work+0x1d4/0x320<br /> worker_thread+0x2cc/0x44c<br /> kthread+0x110/0x114<br /> ret_from_fork+0x10/0x20

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Replace snprintf with scnprintf<br /> <br /> Current code produces a warning as shown below when total characters<br /> in the constituent block device names plus the slashes exceeds 200.<br /> snprintf() returns the number of characters generated from the given<br /> input, which could cause the expression “200 – len” to wrap around<br /> to a large positive number. Fix this by using scnprintf() instead,<br /> which returns the actual number of characters written into the buffer.<br /> <br /> [ 1513.267938] ------------[ cut here ]------------<br /> [ 1513.267943] WARNING: CPU: 15 PID: 37247 at /lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510<br /> [ 1513.267944] Modules linked in: <br /> [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu<br /> [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022<br /> [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510<br /> <br /> [ 1513.267982] Call Trace:<br /> [ 1513.267986] snprintf+0x45/0x70<br /> [ 1513.267990] ? disk_name+0x71/0xa0<br /> [ 1513.267993] dump_zones+0x114/0x240 [raid0]<br /> [ 1513.267996] ? _cond_resched+0x19/0x40<br /> [ 1513.267998] raid0_run+0x19e/0x270 [raid0]<br /> [ 1513.268000] md_run+0x5e0/0xc50<br /> [ 1513.268003] ? security_capable+0x3f/0x60<br /> [ 1513.268005] do_md_run+0x19/0x110<br /> [ 1513.268006] md_ioctl+0x195e/0x1f90<br /> [ 1513.268007] blkdev_ioctl+0x91f/0x9f0<br /> [ 1513.268010] block_ioctl+0x3d/0x50<br /> [ 1513.268012] do_vfs_ioctl+0xa9/0x640<br /> [ 1513.268014] ? __fput+0x162/0x260<br /> [ 1513.268016] ksys_ioctl+0x75/0x80<br /> [ 1513.268017] __x64_sys_ioctl+0x1a/0x20<br /> [ 1513.268019] do_syscall_64+0x5e/0x200<br /> [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9