Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: pci_endpoint_test: Free IRQs before removing the device<br /> <br /> In pci_endpoint_test_remove(), freeing the IRQs after removing the device<br /> creates a small race window for IRQs to be received with the test device<br /> memory already released, causing the IRQ handler to access invalid memory,<br /> resulting in an oops.<br /> <br /> Free the device IRQs before removing the device to avoid this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation<br /> <br /> /dev/vtpmx is made visible before &amp;#39;workqueue&amp;#39; is initialized, which can<br /> lead to a memory corruption in the worst case scenario.<br /> <br /> Address this by initializing &amp;#39;workqueue&amp;#39; as the very first step of the<br /> driver initialization.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race condition<br /> <br /> mptlan_probe() calls mpt_register_lan_device() which initializes the<br /> &amp;priv-&gt;post_buckets_task workqueue. A call to<br /> mpt_lan_wake_post_buckets_task() will subsequently start the work.<br /> <br /> During driver unload in mptlan_remove() the following race may occur:<br /> <br /> CPU0 CPU1<br /> <br /> |mpt_lan_post_receive_buckets_work()<br /> mptlan_remove() |<br /> free_netdev() |<br /> kfree(dev); |<br /> |<br /> | dev-&gt;mtu<br /> | //use<br /> <br /> Fix this by finishing the work prior to cleaning up in mptlan_remove().<br /> <br /> [mkp: we really should remove mptlan instead of attempting to fix it]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix deadlock when converting an inline directory in nojournal mode<br /> <br /> In no journal mode, ext4_finish_convert_inline_dir() can self-deadlock<br /> by calling ext4_handle_dirty_dirblock() when it already has taken the<br /> directory lock. There is a similar self-deadlock in<br /> ext4_incvert_inline_data_nolock() for data files which we&amp;#39;ll fix at<br /> the same time.<br /> <br /> A simple reproducer demonstrating the problem:<br /> <br /> mke2fs -Fq -t ext2 -O inline_data -b 4k /dev/vdc 64<br /> mount -t ext4 -o dirsync /dev/vdc /vdc<br /> cd /vdc<br /> mkdir file0<br /> cd file0<br /> touch file0<br /> touch file1<br /> attr -s BurnSpaceInEA -V abcde .<br /> touch supercalifragilisticexpialidocious

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> samples/bpf: Fix buffer overflow in tcp_basertt<br /> <br /> Using sizeof(nv) or strlen(nv)+1 is correct.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovl: fix null pointer dereference in ovl_get_acl_rcu()<br /> <br /> Following process:<br /> P1 P2<br /> path_openat<br /> link_path_walk<br /> may_lookup<br /> inode_permission(rcu)<br /> ovl_permission<br /> acl_permission_check<br /> check_acl<br /> get_cached_acl_rcu<br /> ovl_get_inode_acl<br /> realinode = ovl_inode_real(ovl_inode)<br /> drop_cache<br /> __dentry_kill(ovl_dentry)<br /> iput(ovl_inode)<br /> ovl_destroy_inode(ovl_inode)<br /> dput(oi-&gt;__upperdentry)<br /> dentry_kill(upperdentry)<br /> dentry_unlink_inode<br /> upperdentry-&gt;d_inode = NULL<br /> ovl_inode_upper<br /> upperdentry = ovl_i_dentry_upper(ovl_inode)<br /> d_inode(upperdentry) // returns NULL<br /> IS_POSIXACL(realinode) // NULL pointer dereference<br /> , will trigger an null pointer dereference at realinode:<br /> [ 205.472797] BUG: kernel NULL pointer dereference, address:<br /> 0000000000000028<br /> [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted<br /> 6.3.0-12064-g2edfa098e750-dirty #1216<br /> [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300<br /> [ 205.489584] Call Trace:<br /> [ 205.489812] <br /> [ 205.490014] ovl_get_inode_acl+0x26/0x30<br /> [ 205.490466] get_cached_acl_rcu+0x61/0xa0<br /> [ 205.490908] generic_permission+0x1bf/0x4e0<br /> [ 205.491447] ovl_permission+0x79/0x1b0<br /> [ 205.491917] inode_permission+0x15e/0x2c0<br /> [ 205.492425] link_path_walk+0x115/0x550<br /> [ 205.493311] path_lookupat.isra.0+0xb2/0x200<br /> [ 205.493803] filename_lookup+0xda/0x240<br /> [ 205.495747] vfs_fstatat+0x7b/0xb0<br /> <br /> Fetch a reproducer in [Link].<br /> <br /> Use the helper ovl_i_path_realinode() to get realinode and then do<br /> non-nullptr checking.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: af9005: Fix null-ptr-deref in af9005_i2c_xfer<br /> <br /> In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf<br /> is null and msg[i].len is zero, former checks on msg[i].buf would be<br /> passed. Malicious data finally reach af9005_i2c_xfer. If accessing<br /> msg[i].buf[0] without sanity check, null ptr deref would happen.<br /> We add check on msg[i].len to prevent crash.<br /> <br /> Similar commit:<br /> commit 0ed554fd769a<br /> ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/powernv/sriov: perform null check on iov before dereferencing iov<br /> <br /> Currently pointer iov is being dereferenced before the null check of iov<br /> which can lead to null pointer dereference errors. Fix this by moving the<br /> iov null check before the dereferencing.<br /> <br /> Detected using cppcheck static analysis:<br /> linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either<br /> the condition &amp;#39;!iov&amp;#39; is redundant or there is possible null pointer<br /> dereference: iov. [nullPointerRedundantCheck]<br /> num_vfs = iov-&gt;num_vfs;<br /> ^

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> refscale: Fix uninitalized use of wait_queue_head_t<br /> <br /> Running the refscale test occasionally crashes the kernel with the<br /> following error:<br /> <br /> [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8<br /> [ 8569.952900] #PF: supervisor read access in kernel mode<br /> [ 8569.952902] #PF: error_code(0x0000) - not-present page<br /> [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0<br /> [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI<br /> [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021<br /> [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190<br /> :<br /> [ 8569.952940] Call Trace:<br /> [ 8569.952941] <br /> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale]<br /> [ 8569.952959] kthread+0x10e/0x130<br /> [ 8569.952966] ret_from_fork+0x1f/0x30<br /> [ 8569.952973] <br /> <br /> The likely cause is that init_waitqueue_head() is called after the call to<br /> the torture_create_kthread() function that creates the ref_scale_reader<br /> kthread. Although this init_waitqueue_head() call will very likely<br /> complete before this kthread is created and starts running, it is<br /> possible that the calling kthread will be delayed between the calls to<br /> torture_create_kthread() and init_waitqueue_head(). In this case, the<br /> new kthread will use the waitqueue head before it is properly initialized,<br /> which is not good for the kernel&amp;#39;s health and well-being.<br /> <br /> The above crash happened here:<br /> <br /> static inline void __add_wait_queue(...)<br /> {<br /> :<br /> if (!(wq-&gt;flags &amp; WQ_FLAG_PRIORITY))

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm flakey: don&amp;#39;t corrupt the zero page<br /> <br /> When we need to zero some range on a block device, the function<br /> __blkdev_issue_zero_pages submits a write bio with the bio vector pointing<br /> to the zero page. If we use dm-flakey with corrupt bio writes option, it<br /> will corrupt the content of the zero page which results in crashes of<br /> various userspace programs. Glibc assumes that memory returned by mmap is<br /> zeroed and it uses it for calloc implementation; if the newly mapped<br /> memory is not zeroed, calloc will return non-zeroed memory.<br /> <br /> Fix this bug by testing if the page is equal to ZERO_PAGE(0) and<br /> avoiding the corruption in this case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: bus: verify partner exists in typec_altmode_attention<br /> <br /> Some usb hubs will negotiate DisplayPort Alt mode with the device<br /> but will then negotiate a data role swap after entering the alt<br /> mode. The data role swap causes the device to unregister all alt<br /> modes, however the usb hub will still send Attention messages<br /> even after failing to reregister the Alt Mode. type_altmode_attention<br /> currently does not verify whether or not a device&amp;#39;s altmode partner<br /> exists, which results in a NULL pointer error when dereferencing<br /> the typec_altmode and typec_altmode_ops belonging to the altmode<br /> partner.<br /> <br /> Verify the presence of a device&amp;#39;s altmode partner before sending<br /> the Attention message to the Alt Mode driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rx<br /> <br /> For the reasons also described in commit b383e8abed41 ("wifi: ath9k: avoid<br /> uninit memory read in ath9k_htc_rx_msg()"), ath9k_htc_rx_msg() should<br /> validate pkt_len before accessing the SKB.<br /> <br /> For example, the obtained SKB may have been badly constructed with<br /> pkt_len = 8. In this case, the SKB can only contain a valid htc_frame_hdr<br /> but after being processed in ath9k_htc_rx_msg() and passed to<br /> ath9k_wmi_ctrl_rx() endpoint RX handler, it is expected to have a WMI<br /> command header which should be located inside its data payload.<br /> <br /> Implement sanity checking inside ath9k_wmi_ctrl_rx(). Otherwise, uninit<br /> memory can be referenced.<br /> <br /> Tested on Qualcomm Atheros Communications AR9271 802.11n .<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.