Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t allow journal inode to have encrypt flag<br /> <br /> Mounting a filesystem whose journal inode has the encrypt flag causes a<br /> NULL dereference in fscrypt_limit_io_blocks() when the &amp;#39;inlinecrypt&amp;#39;<br /> mount option is used.<br /> <br /> The problem is that when jbd2_journal_init_inode() calls bmap(), it<br /> eventually finds its way into ext4_iomap_begin(), which calls<br /> fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if<br /> the inode is encrypted, then its encryption key must already be set up.<br /> That&amp;#39;s not the case here, since the journal inode is never "opened" like<br /> a normal file would be. Hence the crash.<br /> <br /> A reproducer is:<br /> <br /> mkfs.ext4 -F /dev/vdb<br /> debugfs -w /dev/vdb -R "set_inode_field flags 0x80808"<br /> mount /dev/vdb /mnt -o inlinecrypt<br /> <br /> To fix this, make ext4 consider journal inodes with the encrypt flag to<br /> be invalid. (Note, maybe other flags should be rejected on the journal<br /> inode too. For now, this is just the minimal fix for the above issue.)<br /> <br /> I&amp;#39;ve marked this as fixing the commit that introduced the call to<br /> fscrypt_limit_io_blocks(), since that&amp;#39;s what made an actual crash start<br /> being possible. But this fix could be applied to any version of ext4<br /> that supports the encrypt feature.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PNP: fix name memory leak in pnp_alloc_dev()<br /> <br /> After commit 1fa5ae857bb1 ("driver core: get rid of struct device&amp;#39;s<br /> bus_id string array"), the name of device is allocated dynamically,<br /> move dev_set_name() after pnp_add_id() to avoid memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()<br /> <br /> There is a global-out-of-bounds reported by KASAN:<br /> <br /> BUG: KASAN: global-out-of-bounds in<br /> _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]<br /> Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411<br /> <br /> CPU: 6 PID: 411 Comm: NetworkManager Tainted: G D<br /> 6.1.0-rc8+ #144 e15588508517267d37<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),<br /> Call Trace:<br /> <br /> ...<br /> kasan_report+0xbb/0x1c0<br /> _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]<br /> rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]<br /> rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]<br /> ...<br /> <br /> <br /> The root cause of the problem is that the comparison order of<br /> "prate_section" in _rtl8812ae_phy_set_txpower_limit() is wrong. The<br /> _rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two<br /> strings from tail to head, which causes the problem. In the<br /> _rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet<br /> this requirement by carefully designing the comparison order.<br /> For example, "pregulation" and "pbandwidth" are compared in order of<br /> length from small to large, first is 3 and last is 4. However, the<br /> comparison order of "prate_section" dose not obey such order requirement,<br /> therefore when "prate_section" is "HT", when comparing from tail to head,<br /> it will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As<br /> mentioned above, the _rtl8812ae_eq_n_byte() has the same function as<br /> strcmp(), so just strcmp() is enough.<br /> <br /> Fix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.<br /> Although it can be fixed by adjusting the comparison order of<br /> "prate_section", this may cause the value of "rate_section" to not be<br /> from 0 to 5. In addition, commit "21e4b0726dc6" not only moved driver<br /> from staging to regular tree, but also added setting txpower limit<br /> function during the driver config phase, so the problem was introduced<br /> by this commit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: annotate data-races around kcm-&gt;rx_wait<br /> <br /> kcm-&gt;rx_psock can be read locklessly in kcm_rfree().<br /> Annotate the read and writes accordingly.<br /> <br /> syzbot reported:<br /> <br /> BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree<br /> <br /> write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:<br /> reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]<br /> kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363<br /> __strp_recv+0x64c/0xd20 net/strparser/strparser.c:301<br /> strp_recv+0x6d/0x80 net/strparser/strparser.c:335<br /> tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703<br /> strp_read_sock net/strparser/strparser.c:358 [inline]<br /> do_strp_work net/strparser/strparser.c:406 [inline]<br /> strp_work+0xe8/0x180 net/strparser/strparser.c:415<br /> process_one_work+0x3d3/0x720 kernel/workqueue.c:2289<br /> worker_thread+0x618/0xa70 kernel/workqueue.c:2436<br /> kthread+0x1a9/0x1e0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br /> <br /> read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:<br /> kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181<br /> skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841<br /> skb_release_all net/core/skbuff.c:852 [inline]<br /> __kfree_skb net/core/skbuff.c:868 [inline]<br /> kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891<br /> kfree_skb include/linux/skbuff.h:1216 [inline]<br /> kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161<br /> ____sys_recvmsg+0x16c/0x2e0<br /> ___sys_recvmsg net/socket.c:2743 [inline]<br /> do_recvmmsg+0x2f1/0x710 net/socket.c:2837<br /> __sys_recvmmsg net/socket.c:2916 [inline]<br /> __do_sys_recvmmsg net/socket.c:2939 [inline]<br /> __se_sys_recvmmsg net/socket.c:2932 [inline]<br /> __x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> value changed: 0x01 -&gt; 0x00<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kprobes: Fix check for probe enabled in kill_kprobe()<br /> <br /> In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be<br /> called always fails. This is because before that we set the<br /> KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always<br /> false.<br /> <br /> The disarm_kprobe_ftrace() call introduced by commit:<br /> <br /> 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler")<br /> <br /> to fix the NULL pointer reference problem. When the probe is enabled, if<br /> we do not disarm it, this problem still exists.<br /> <br /> Fix it by putting the probe enabled check before setting the<br /> KPROBE_FLAG_GONE flag.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: rtsx_pci: 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 calling mmc_free_host() in the<br /> error path, beside, runtime PM also needs be disabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: moxart: 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 /> drm/vkms: Fix memory leak in vkms_init()<br /> <br /> A memory leak was reported after the vkms module install failed.<br /> <br /> unreferenced object 0xffff88810bc28520 (size 16):<br /> comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s)<br /> hex dump (first 16 bytes):<br /> 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............<br /> backtrace:<br /> [] kmalloc_trace+0x27/0x60<br /> [] 0xffffffffc45200a9<br /> [] do_one_initcall+0xd0/0x4f0<br /> [] do_init_module+0x1a4/0x680<br /> [] load_module+0x6249/0x7110<br /> [] __do_sys_finit_module+0x140/0x200<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The reason is that the vkms_init() returns without checking the return<br /> value of vkms_create(), and if the vkms_create() failed, the config<br /> allocated at the beginning of vkms_init() is leaked.<br /> <br /> vkms_init()<br /> config = kmalloc(...) # config allocated<br /> ...<br /> return vkms_create() # vkms_create failed and config is leaked<br /> <br /> Fix this problem by checking return value of vkms_create() and free the<br /> config if error happened.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix the assign logic of iocb<br /> <br /> commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")<br /> introduces iocb field in &amp;#39;f2fs_direct_IO_enter&amp;#39; trace event<br /> And it only assigns the pointer and later it accesses its field<br /> in trace print log.<br /> <br /> Unable to handle kernel paging request at virtual address ffffffc04cef3d30<br /> Mem abort info:<br /> ESR = 0x96000007<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> <br /> pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4<br /> lr : trace_raw_output_f2fs_direct_IO_enter+0x2c/0xa4<br /> sp : ffffffc0443cbbd0<br /> x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108<br /> x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0<br /> x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c<br /> x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060<br /> x17: ffffff8935b11e76 x16: 00000000000000cc x15: ffffffef855c4f2c<br /> x14: 0000000000000001 x13: 000000000000004e x12: ffff0000ffffff00<br /> x11: ffffffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c<br /> x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 0000000002000000<br /> x5 : ffffff8935b11e9a x4 : 0000000000006250 x3 : ffff0a00ffffff04<br /> x2 : 0000000000000002 x1 : ffffffef86a0a31f x0 : ffffff8935b10000<br /> Call trace:<br /> trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4<br /> print_trace_fmt+0x9c/0x138<br /> print_trace_line+0x154/0x254<br /> tracing_read_pipe+0x21c/0x380<br /> vfs_read+0x108/0x3ac<br /> ksys_read+0x7c/0xec<br /> __arm64_sys_read+0x20/0x30<br /> invoke_syscall+0x60/0x150<br /> el0_svc_common.llvm.1237943816091755067+0xb8/0xf8<br /> do_el0_svc+0x28/0xa0<br /> <br /> Fix it by copying the required variables for printing and while at<br /> it fix the similar issue at some other places in the same file.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost/vsock: Use kvmalloc/kvfree for larger packets.<br /> <br /> When copying a large file over sftp over vsock, data size is usually 32kB,<br /> and kmalloc seems to fail to try to allocate 32 32kB regions.<br /> <br /> vhost-5837: page allocation failure: order:4, mode:0x24040c0<br /> Call Trace:<br /> [] dump_stack+0x97/0xdb<br /> [] warn_alloc_failed+0x10f/0x138<br /> [] ? __alloc_pages_direct_compact+0x38/0xc8<br /> [] __alloc_pages_nodemask+0x84c/0x90d<br /> [] alloc_kmem_pages+0x17/0x19<br /> [] kmalloc_order_trace+0x2b/0xdb<br /> [] __kmalloc+0x177/0x1f7<br /> [] ? copy_from_iter+0x8d/0x31d<br /> [] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock]<br /> [] vhost_worker+0xf7/0x157 [vhost]<br /> [] kthread+0xfd/0x105<br /> [] ? vhost_dev_set_owner+0x22e/0x22e [vhost]<br /> [] ? flush_kthread_worker+0xf3/0xf3<br /> [] ret_from_fork+0x4e/0x80<br /> [] ? flush_kthread_worker+0xf3/0xf3<br /> <br /> Work around by doing kvmalloc instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Validate BOOT record_size<br /> <br /> When the NTFS BOOT record_size field record_bits calculation through blksize_bits() assumes<br /> the size always &gt; 256, which could lead to NPD while mounting a<br /> malformed NTFS image.<br /> <br /> [ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158<br /> [ 318.675682] #PF: supervisor read access in kernel mode<br /> [ 318.675869] #PF: error_code(0x0000) - not-present page<br /> [ 318.676246] PGD 0 P4D 0<br /> [ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5<br /> [ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0<br /> [ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180<br /> [ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246<br /> [ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080<br /> [ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> [ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080<br /> [ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000<br /> [ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000<br /> [ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0<br /> [ 318.685623] Call Trace:<br /> [ 318.686607] <br /> [ 318.686872] ? ntfs_alloc_inode+0x1a/0x60<br /> [ 318.687235] attr_load_runs_vcn+0x2b/0xa0<br /> [ 318.687468] mi_read+0xbb/0x250<br /> [ 318.687576] ntfs_iget5+0x114/0xd90<br /> [ 318.687750] ntfs_fill_super+0x588/0x11b0<br /> [ 318.687953] ? put_ntfs+0x130/0x130<br /> [ 318.688065] ? snprintf+0x49/0x70<br /> [ 318.688164] ? put_ntfs+0x130/0x130<br /> [ 318.688256] get_tree_bdev+0x16a/0x260<br /> [ 318.688407] vfs_get_tree+0x20/0xb0<br /> [ 318.688519] path_mount+0x2dc/0x9b0<br /> [ 318.688877] do_mount+0x74/0x90<br /> [ 318.689142] __x64_sys_mount+0x89/0xd0<br /> [ 318.689636] do_syscall_64+0x3b/0x90<br /> [ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 318.690318] RIP: 0033:0x7fd9e133c48a<br /> [ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5<br /> [ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a<br /> [ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0<br /> [ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020<br /> [ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0<br /> [ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 318.693007] <br /> [ 318.693271] Modules linked in:<br /> [ 318.693614] CR2: 0000000000000158<br /> [ 318.694446] ---[ end trace 0000000000000000 ]---<br /> [ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0<br /> [ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180<br /> [ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246<br /> [ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080<br /> [ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000<br /> [ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080<br /> [ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000<br /> [ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000<br /> [<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpasim: fix memory leak when freeing IOTLBs<br /> <br /> After commit bda324fd037a ("vdpasim: control virtqueue support"),<br /> vdpasim-&gt;iommu became an array of IOTLB, so we should clean the<br /> mappings of each free one by one instead of just deleting the ranges<br /> in the first IOTLB which may leak maps.