Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_dsp_rproc: Add custom memory copy implementation for i.MX DSP Cores<br /> <br /> The IRAM is part of the HiFi DSP.<br /> According to hardware specification only 32-bits write are allowed<br /> otherwise we get a Kernel panic.<br /> <br /> Therefore add a custom memory copy and memset functions to deal with<br /> the above restriction.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cassini: Fix a memory leak in the error handling path of cas_init_one()<br /> <br /> cas_saturn_firmware_init() allocates some memory using vmalloc(). This<br /> memory is freed in the .remove() function but not it the error handling<br /> path of the probe.<br /> <br /> Add the missing vfree() to avoid a memory leak, should an error occur.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: snic: Fix possible memory leak if device_add() fails<br /> <br /> If device_add() returns error, the name allocated by dev_set_name() needs<br /> be freed. As the comment of device_add() says, put_device() should be used<br /> to give up the reference in the error path. So fix this by calling<br /> put_device(), then the name can be freed in kobject_cleanp().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Handle cameras with invalid descriptors<br /> <br /> If the source entity does not contain any pads, do not create a link.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/MCE: Always save CS register on AMD Zen IF Poison errors<br /> <br /> The Instruction Fetch (IF) units on current AMD Zen-based systems do not<br /> guarantee a synchronous #MC is delivered for poison consumption errors.<br /> Therefore, MCG_STATUS[EIPV|RIPV] will not be set. However, the<br /> microarchitecture does guarantee that the exception is delivered within<br /> the same context. In other words, the exact rIP is not known, but the<br /> context is known to not have changed.<br /> <br /> There is no architecturally-defined method to determine this behavior.<br /> <br /> The Code Segment (CS) register is always valid on such IF unit poison<br /> errors regardless of the value of MCG_STATUS[EIPV|RIPV].<br /> <br /> Add a quirk to save the CS register for poison consumption from the IF<br /> unit banks.<br /> <br /> This is needed to properly determine the context of the error.<br /> Otherwise, the severity grading function will assume the context is<br /> IN_KERNEL due to the m-&gt;cs value being 0 (the initialized value). This<br /> leads to unnecessary kernel panics on data poison errors due to the<br /> kernel believing the poison consumption occurred in kernel context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fw: fix memory leak in debugfs<br /> <br /> Fix a memory leak that occurs when reading the fw_info<br /> file all the way, since we return NULL indicating no<br /> more data, but don&amp;#39;t free the status tracking object.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> objtool: Fix memory leak in create_static_call_sections()<br /> <br /> strdup() allocates memory for key_name. We need to release the memory in<br /> the following error paths. Add free() to avoid memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: fix of_iomap memory leak<br /> <br /> Smatch reports:<br /> drivers/clk/mediatek/clk-mtk.c:583 mtk_clk_simple_probe() warn:<br /> &amp;#39;base&amp;#39; from of_iomap() not released on lines: 496.<br /> <br /> This problem was also found in linux-next. In mtk_clk_simple_probe(),<br /> base is not released when handling errors<br /> if clk_data is not existed, which may cause a leak.<br /> So free_base should be added here to release base.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: platform: mediatek: vpu: fix NULL ptr dereference<br /> <br /> If pdev is NULL, then it is still dereferenced.<br /> <br /> This fixes this smatch warning:<br /> <br /> drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer &amp;#39;pdev&amp;#39;

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: Fix xsk_diag use-after-free error during socket cleanup<br /> <br /> Fix a use-after-free error that is possible if the xsk_diag interface<br /> is used after the socket has been unbound from the device. This can<br /> happen either due to the socket being closed or the device<br /> disappearing. In the early days of AF_XDP, the way we tested that a<br /> socket was not bound to a device was to simply check if the netdevice<br /> pointer in the xsk socket structure was NULL. Later, a better system<br /> was introduced by having an explicit state variable in the xsk socket<br /> struct. For example, the state of a socket that is on the way to being<br /> closed and has been unbound from the device is XSK_UNBOUND.<br /> <br /> The commit in the Fixes tag below deleted the old way of signalling<br /> that a socket is unbound, setting dev to NULL. This in the belief that<br /> all code using the old way had been exterminated. That was<br /> unfortunately not true as the xsk diagnostics code was still using the<br /> old way and thus does not work as intended when a socket is going<br /> down. Fix this by introducing a test against the state variable. If<br /> the socket is in the state XSK_UNBOUND, simply abort the diagnostic&amp;#39;s<br /> netlink operation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix warning and UAF when destroy the MR list<br /> <br /> If the MR allocate failed, the MR recovery work not initialized<br /> and list not cleared. Then will be warning and UAF when release<br /> the MR:<br /> <br /> WARNING: CPU: 4 PID: 824 at kernel/workqueue.c:3066 __flush_work.isra.0+0xf7/0x110<br /> CPU: 4 PID: 824 Comm: mount.cifs Not tainted 6.1.0-rc5+ #82<br /> RIP: 0010:__flush_work.isra.0+0xf7/0x110<br /> Call Trace:<br /> <br /> __cancel_work_timer+0x2ba/0x2e0<br /> smbd_destroy+0x4e1/0x990<br /> _smbd_get_connection+0x1cbd/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> BUG: KASAN: use-after-free in smbd_destroy+0x4fc/0x990<br /> Read of size 8 at addr ffff88810b156a08 by task mount.cifs/824<br /> CPU: 4 PID: 824 Comm: mount.cifs Tainted: G W 6.1.0-rc5+ #82<br /> Call Trace:<br /> dump_stack_lvl+0x34/0x44<br /> print_report+0x171/0x472<br /> kasan_report+0xad/0x130<br /> smbd_destroy+0x4fc/0x990<br /> _smbd_get_connection+0x1cbd/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Allocated by task 824:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0x7a/0x90<br /> _smbd_get_connection+0x1b6f/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Freed by task 824:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x40<br /> ____kasan_slab_free+0x143/0x1b0<br /> __kmem_cache_free+0xc8/0x330<br /> _smbd_get_connection+0x1c6a/0x2110<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Let&amp;#39;s initialize the MR recovery work before MR allocate to prevent<br /> the warning, remove the MRs from the list to prevent the UAF.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powercap: arm_scmi: Remove recursion while parsing zones<br /> <br /> Powercap zones can be defined as arranged in a hierarchy of trees and when<br /> registering a zone with powercap_register_zone(), the kernel powercap<br /> subsystem expects this to happen starting from the root zones down to the<br /> leaves; on the other side, de-registration by powercap_deregister_zone()<br /> must begin from the leaf zones.<br /> <br /> Available SCMI powercap zones are retrieved dynamically from the platform<br /> at probe time and, while any defined hierarchy between the zones is<br /> described properly in the zones descriptor, the platform returns the<br /> availables zones with no particular well-defined order: as a consequence,<br /> the trees possibly composing the hierarchy of zones have to be somehow<br /> walked properly to register the retrieved zones from the root.<br /> <br /> Currently the ARM SCMI Powercap driver walks the zones using a recursive<br /> algorithm; this approach, even though correct and tested can lead to kernel<br /> stack overflow when processing a returned hierarchy of zones composed by<br /> particularly high trees.<br /> <br /> Avoid possible kernel stack overflow by substituting the recursive approach<br /> with an iterative one supported by a dynamically allocated stack-like data<br /> structure.