Vulnerabilidades

*** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: Avoid double brelse() in udf_rename()<br /> <br /> syzbot reported a warning like below [1]:<br /> <br /> VFS: brelse: Trying to free free buffer<br /> WARNING: CPU: 2 PID: 7301 at fs/buffer.c:1145 __brelse+0x67/0xa0<br /> ...<br /> Call Trace:<br /> <br /> invalidate_bh_lru+0x99/0x150<br /> smp_call_function_many_cond+0xe2a/0x10c0<br /> ? generic_remap_file_range_prep+0x50/0x50<br /> ? __brelse+0xa0/0xa0<br /> ? __mutex_lock+0x21c/0x12d0<br /> ? smp_call_on_cpu+0x250/0x250<br /> ? rcu_read_lock_sched_held+0xb/0x60<br /> ? lock_release+0x587/0x810<br /> ? __brelse+0xa0/0xa0<br /> ? generic_remap_file_range_prep+0x50/0x50<br /> on_each_cpu_cond_mask+0x3c/0x80<br /> blkdev_flush_mapping+0x13a/0x2f0<br /> blkdev_put_whole+0xd3/0xf0<br /> blkdev_put+0x222/0x760<br /> deactivate_locked_super+0x96/0x160<br /> deactivate_super+0xda/0x100<br /> cleanup_mnt+0x222/0x3d0<br /> task_work_run+0x149/0x240<br /> ? task_work_cancel+0x30/0x30<br /> do_exit+0xb29/0x2a40<br /> ? reacquire_held_locks+0x4a0/0x4a0<br /> ? do_raw_spin_lock+0x12a/0x2b0<br /> ? mm_update_next_owner+0x7c0/0x7c0<br /> ? rwlock_bug.part.0+0x90/0x90<br /> ? zap_other_threads+0x234/0x2d0<br /> do_group_exit+0xd0/0x2a0<br /> __x64_sys_exit_group+0x3a/0x50<br /> do_syscall_64+0x34/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The cause of the issue is that brelse() is called on both ofibh.sbh<br /> and ofibh.ebh by udf_find_entry() when it returns NULL. However,<br /> brelse() is called by udf_rename(), too. So, b_count on buffer_head<br /> becomes unbalanced.<br /> <br /> This patch fixes the issue by not calling brelse() by udf_rename()<br /> when udf_find_entry() returns NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix mempool alloc size<br /> <br /> Convert the max size to bytes to match the units of the divisor that<br /> calculates the worst-case number of PRP entries.<br /> <br /> The result is used to determine how many PRP Lists are required. The<br /> code was previously rounding this to 1 list, but we can require 2 in the<br /> worst case. In that scenario, the driver would corrupt memory beyond the<br /> size provided by the mempool.<br /> <br /> While unlikely to occur (you&amp;#39;d need a 4MB in exactly 127 phys segments<br /> on a queue that doesn&amp;#39;t support SGLs), this memory corruption has been<br /> observed by kfence.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: camss: Clean up received buffers on failed start of streaming<br /> <br /> It is required to return the received buffers, if streaming can not be<br /> started. For instance media_pipeline_start() may fail with EPIPE, if<br /> a link validation between entities is not passed, and in such a case<br /> a user gets a kernel warning:<br /> <br /> WARNING: CPU: 1 PID: 520 at drivers/media/common/videobuf2/videobuf2-core.c:1592 vb2_start_streaming+0xec/0x160<br /> <br /> Call trace:<br /> vb2_start_streaming+0xec/0x160<br /> vb2_core_streamon+0x9c/0x1a0<br /> vb2_ioctl_streamon+0x68/0xbc<br /> v4l_streamon+0x30/0x3c<br /> __video_do_ioctl+0x184/0x3e0<br /> video_usercopy+0x37c/0x7b0<br /> video_ioctl2+0x24/0x40<br /> v4l2_ioctl+0x4c/0x70<br /> <br /> The fix is to correct the error path in video_start_streaming() of camss.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: vt6655: fix potential memory leak<br /> <br /> In function device_init_td0_ring, memory is allocated for member<br /> td_info of priv-&gt;apTD0Rings[i], with i increasing from 0. In case of<br /> allocation failure, the memory is freed in reversed order, with i<br /> decreasing to 0. However, the case i=0 is left out and thus memory is<br /> leaked.<br /> <br /> Modify the memory freeing loop to include the case i=0.