Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fortify: Fix __compiletime_strlen() under UBSAN_BOUNDS_LOCAL<br /> <br /> With CONFIG_FORTIFY=y and CONFIG_UBSAN_LOCAL_BOUNDS=y enabled, we observe<br /> a runtime panic while running Android&amp;#39;s Compatibility Test Suite&amp;#39;s (CTS)<br /> android.hardware.input.cts.tests. This is stemming from a strlen()<br /> call in hidinput_allocate().<br /> <br /> __compiletime_strlen() is implemented in terms of __builtin_object_size(),<br /> then does an array access to check for NUL-termination. A quirk of<br /> __builtin_object_size() is that for strings whose values are runtime<br /> dependent, __builtin_object_size(str, 1 or 0) returns the maximum size<br /> of possible values when those sizes are determinable at compile time.<br /> Example:<br /> <br /> static const char *v = "FOO BAR";<br /> static const char *y = "FOO BA";<br /> unsigned long x (int z) {<br /> // Returns 8, which is:<br /> // max(__builtin_object_size(v, 1), __builtin_object_size(y, 1))<br /> return __builtin_object_size(z ? v : y, 1);<br /> }<br /> <br /> So when FORTIFY_SOURCE is enabled, the current implementation of<br /> __compiletime_strlen() will try to access beyond the end of y at runtime<br /> using the size of v. Mixed with UBSAN_LOCAL_BOUNDS we get a fault.<br /> <br /> hidinput_allocate() has a local C string whose value is control flow<br /> dependent on a switch statement, so __builtin_object_size(str, 1)<br /> evaluates to the maximum string length, making all other cases fault on<br /> the last character check. hidinput_allocate() could be cleaned up to<br /> avoid runtime calls to strlen() since the local variable can only have<br /> literal values, so there&amp;#39;s no benefit to trying to fortify the strlen<br /> call site there.<br /> <br /> Perform a __builtin_constant_p() check against index 0 earlier in the<br /> macro to filter out the control-flow-dependant case. Add a KUnit test<br /> for checking the expected behavioral characteristics of FORTIFY_SOURCE<br /> internals.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> orangefs: Fix kmemleak in orangefs_prepare_debugfs_help_string()<br /> <br /> When insert and remove the orangefs module, then debug_help_string will<br /> be leaked:<br /> <br /> unreferenced object 0xffff8881652ba000 (size 4096):<br /> comm "insmod", pid 1701, jiffies 4294893639 (age 13218.530s)<br /> hex dump (first 32 bytes):<br /> 43 6c 69 65 6e 74 20 44 65 62 75 67 20 4b 65 79 Client Debug Key<br /> 77 6f 72 64 73 20 61 72 65 20 75 6e 6b 6e 6f 77 words are unknow<br /> backtrace:<br /> [] kmalloc_trace+0x27/0xa0<br /> [] orangefs_prepare_debugfs_help_string+0x5e/0x480 [orangefs]<br /> [] _sub_I_65535_1+0x57/0xf70 [crc_itu_t]<br /> [] do_one_initcall+0x87/0x2a0<br /> [] do_init_module+0xdf/0x320<br /> [] load_module+0x2f98/0x3330<br /> [] __do_sys_finit_module+0x113/0x1b0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> When remove the module, should always free debug_help_string. Should<br /> always free the allocated buffer when change the free_debug_help_string.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failed<br /> <br /> When the ops_init() interface is invoked to initialize the net, but<br /> ops-&gt;init() fails, data is released. However, the ptr pointer in<br /> net-&gt;gen is invalid. In this case, when nfqnl_nf_hook_drop() is invoked<br /> to release the net, invalid address access occurs.<br /> <br /> The process is as follows:<br /> setup_net()<br /> ops_init()<br /> data = kzalloc(...) ---&gt; alloc "data"<br /> net_assign_generic() ---&gt; assign "date" to ptr in net-&gt;gen<br /> ...<br /> ops-&gt;init() ---&gt; failed<br /> ...<br /> kfree(data); ---&gt; ptr in net-&gt;gen is invalid<br /> ...<br /> ops_exit_list()<br /> ...<br /> nfqnl_nf_hook_drop()<br /> *q = nfnl_queue_pernet(net) ---&gt; q is invalid<br /> <br /> The following is the Call Trace information:<br /> BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280<br /> Read of size 8 at addr ffff88810396b240 by task ip/15855<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8e/0xd1<br /> print_report+0x155/0x454<br /> kasan_report+0xba/0x1f0<br /> nfqnl_nf_hook_drop+0x264/0x280<br /> nf_queue_nf_hook_drop+0x8b/0x1b0<br /> __nf_unregister_net_hook+0x1ae/0x5a0<br /> nf_unregister_net_hooks+0xde/0x130<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 /> <br /> <br /> Allocated by task 15855:<br /> kasan_save_stack+0x1e/0x40<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0xa1/0xb0<br /> __kmalloc+0x49/0xb0<br /> ops_init+0xe7/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 15855:<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 /> ops_init+0xb9/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 /> 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.