Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> amdgpu/pm: prevent array underflow in vega20_odn_edit_dpm_table()<br /> <br /> In the PP_OD_EDIT_VDDC_CURVE case the "input_index" variable is capped at<br /> 2 but not checked for negative values so it results in an out of bounds<br /> read. This value comes from the user via sysfs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: marvell/octeontx - prevent integer overflows<br /> <br /> The "code_length" value comes from the firmware file. If your firmware<br /> is untrusted realistically there is probably very little you can do to<br /> protect yourself. Still we try to limit the damage as much as possible.<br /> Also Smatch marks any data read from the filesystem as untrusted and<br /> prints warnings if it not capped correctly.<br /> <br /> The "code_length * 2" can overflow. The round_up(ucode_size, 16) +<br /> sizeof() expression can overflow too. Prevent these overflows.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6/sit: use DEV_STATS_INC() to avoid data-races<br /> <br /> syzbot/KCSAN reported that multiple cpus are updating dev-&gt;stats.tx_error<br /> concurrently.<br /> <br /> This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()<br /> is not protected by a spinlock.<br /> <br /> While original KCSAN report was about tx path, rx path has the same issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: kexec: Fix memory leak of elf header buffer<br /> <br /> This is reported by kmemleak detector:<br /> <br /> unreferenced object 0xff2000000403d000 (size 4096):<br /> comm "kexec", pid 146, jiffies 4294900633 (age 64.792s)<br /> hex dump (first 32 bytes):<br /> 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............<br /> 04 00 f3 00 01 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmemleak_vmalloc+0x3c/0xbe<br /> [] __vmalloc_node_range+0x3ac/0x560<br /> [] __vmalloc_node+0x56/0x62<br /> [] vzalloc+0x2c/0x34<br /> [] crash_prepare_elf64_headers+0x80/0x30c<br /> [] elf_kexec_load+0x3e8/0x4ec<br /> [] kexec_image_load_default+0x40/0x4c<br /> [] sys_kexec_file_load+0x1c4/0x322<br /> [] ret_from_syscall+0x0/0x2<br /> <br /> In elf_kexec_load(), a buffer is allocated via vzalloc() to store elf<br /> headers. While it&amp;#39;s not freed back to system when kdump kernel is<br /> reloaded or unloaded, or when image-&gt;elf_header is successfully set and<br /> then fails to load kdump kernel for some reason. Fix it by freeing the<br /> buffer in arch_kimage_file_post_load_cleanup().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffer<br /> <br /> syzbot is reporting uninit-value in btrfs_clean_tree_block() [1], for<br /> commit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code")<br /> missed that btrfs_set_header_generation() in btrfs_init_new_buffer() must<br /> not be moved to after clean_tree_block() because clean_tree_block() is<br /> calling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs:<br /> Fix extent_buffer usage when nodesize != leafsize").<br /> <br /> Since memzero_extent_buffer() will reset "struct btrfs_header" part, we<br /> can&amp;#39;t move btrfs_set_header_generation() to before memzero_extent_buffer().<br /> Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: smscufx: Fix several use-after-free bugs<br /> <br /> Several types of UAFs can occur when physically removing a USB device.<br /> <br /> Adds ufx_ops_destroy() function to .fb_destroy of fb_ops, and<br /> in this function, there is kref_put() that finally calls ufx_free().<br /> <br /> This fix prevents multiple UAFs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: smartpqi: Correct device removal for multi-actuator devices<br /> <br /> Correct device count for multi-actuator drives which can cause kernel<br /> panics.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: mxcmmc: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and goto error path which will call<br /> mmc_free_host().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix memory leak in ocfs2_mount_volume()<br /> <br /> There is a memory leak reported by kmemleak:<br /> <br /> unreferenced object 0xffff88810cc65e60 (size 32):<br /> comm "mount.ocfs2", pid 23753, jiffies 4302528942 (age 34735.105s)<br /> hex dump (first 32 bytes):<br /> 10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 ................<br /> 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc+0x4d/0x150<br /> [] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]<br /> [] ocfs2_check_volume+0x485/0x900 [ocfs2]<br /> [] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]<br /> [] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]<br /> [] mount_bdev+0x312/0x400<br /> [] legacy_get_tree+0xed/0x1d0<br /> [] vfs_get_tree+0x7d/0x230<br /> [] path_mount+0xd62/0x1760<br /> [] do_mount+0xca/0xe0<br /> [] __x64_sys_mount+0x12c/0x1a0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> This call stack is related to two problems. Firstly, the ocfs2 super uses<br /> "replay_map" to trace online/offline slots, in order to recover offline<br /> slots during recovery and mount. But when ocfs2_truncate_log_init()<br /> returns an error in ocfs2_mount_volume(), the memory of "replay_map" will<br /> not be freed in error handling path. Secondly, the memory of "replay_map"<br /> will not be freed if d_make_root() returns an error in ocfs2_fill_super().<br /> But the memory of "replay_map" will be freed normally when completing<br /> recovery and mount in ocfs2_complete_mount_recovery().<br /> <br /> Fix the first problem by adding error handling path to free "replay_map"<br /> when ocfs2_truncate_log_init() fails. And fix the second problem by<br /> calling ocfs2_free_replay_slots(osb) in the error handling path<br /> "out_dismount". In addition, since ocfs2_free_replay_slots() is static,<br /> it is necessary to remove its static attribute and declare it in header<br /> file.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()<br /> <br /> Running rcutorture with non-zero fqs_duration module parameter in a<br /> kernel built with CONFIG_PREEMPTION=y results in the following splat:<br /> <br /> BUG: using __this_cpu_read() in preemptible [00000000]<br /> code: rcu_torture_fqs/398<br /> caller is __this_cpu_preempt_check+0x13/0x20<br /> CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x5b/0x86<br /> dump_stack+0x10/0x16<br /> check_preemption_disabled+0xe5/0xf0<br /> __this_cpu_preempt_check+0x13/0x20<br /> rcu_force_quiescent_state.part.0+0x1c/0x170<br /> rcu_force_quiescent_state+0x1e/0x30<br /> rcu_torture_fqs+0xca/0x160<br /> ? rcu_torture_boost+0x430/0x430<br /> kthread+0x192/0x1d0<br /> ? kthread_complete_and_exit+0x30/0x30<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> The problem is that rcu_force_quiescent_state() uses __this_cpu_read()<br /> in preemptible code instead of the proper raw_cpu_read(). This commit<br /> therefore changes __this_cpu_read() to raw_cpu_read().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on summary info<br /> <br /> As Wenqing Liu reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=216456<br /> <br /> BUG: KASAN: use-after-free in recover_data+0x63ae/0x6ae0 [f2fs]<br /> Read of size 4 at addr ffff8881464dcd80 by task mount/1013<br /> <br /> CPU: 3 PID: 1013 Comm: mount Tainted: G W 6.0.0-rc4 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> dump_stack_lvl+0x45/0x5e<br /> print_report.cold+0xf3/0x68d<br /> kasan_report+0xa8/0x130<br /> recover_data+0x63ae/0x6ae0 [f2fs]<br /> f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]<br /> f2fs_fill_super+0x4665/0x61e0 [f2fs]<br /> mount_bdev+0x2cf/0x3b0<br /> legacy_get_tree+0xed/0x1d0<br /> vfs_get_tree+0x81/0x2b0<br /> path_mount+0x47e/0x19d0<br /> do_mount+0xce/0xf0<br /> __x64_sys_mount+0x12c/0x1a0<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The root cause is: in fuzzed image, SSA table is corrupted: ofs_in_node<br /> is larger than ADDRS_PER_PAGE(), result in out-of-range access on 4k-size<br /> page.<br /> <br /> - recover_data<br /> - do_recover_data<br /> - check_index_in_prev_nodes<br /> - f2fs_data_blkaddr<br /> <br /> This patch adds sanity check on summary info in recovery and GC flow<br /> in where the flows rely on them.<br /> <br /> After patch:<br /> [ 29.310883] F2FS-fs (loop0): Inconsistent ofs_in_node:65286 in summary, ino:0, nid:6, max:1018

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: fix a memleak in multi_transaction_new()<br /> <br /> In multi_transaction_new(), the variable t is not freed or passed out<br /> on the failure of copy_from_user(t-&gt;data, buf, size), which could lead<br /> to a memleak.<br /> <br /> Fix this bug by adding a put_multi_transaction(t) in the error path.