Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: don&amp;#39;t check if plane-&gt;state-&gt;fb == state-&gt;fb<br /> <br /> Currently, when using non-blocking commits, we can see the following<br /> kernel warning:<br /> <br /> [ 110.908514] ------------[ cut here ]------------<br /> [ 110.908529] refcount_t: underflow; use-after-free.<br /> [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0<br /> [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6<br /> [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32<br /> [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)<br /> [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0<br /> [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0<br /> [ 110.909170] sp : ffffffc00913b9c0<br /> [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60<br /> [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480<br /> [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78<br /> [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000<br /> [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004<br /> [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003<br /> [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00<br /> [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572<br /> [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000<br /> [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001<br /> [ 110.909434] Call trace:<br /> [ 110.909441] refcount_dec_not_one+0xb8/0xc0<br /> [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]<br /> [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]<br /> [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]<br /> [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]<br /> [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]<br /> [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]<br /> [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]<br /> [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]<br /> [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]<br /> [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]<br /> [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4<br /> [ 110.914873] invoke_syscall+0x4c/0x114<br /> [ 110.914897] el0_svc_common+0xd0/0x118<br /> [ 110.914917] do_el0_svc+0x38/0xd0<br /> [ 110.914936] el0_svc+0x30/0x8c<br /> [ 110.914958] el0t_64_sync_handler+0x84/0xf0<br /> [ 110.914979] el0t_64_sync+0x18c/0x190<br /> [ 110.914996] ---[ end trace 0000000000000000 ]---<br /> <br /> This happens because, although `prepare_fb` and `cleanup_fb` are<br /> perfectly balanced, we cannot guarantee consistency in the check<br /> plane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increase<br /> the refcount in `prepare_fb` and don&amp;#39;t decrease it in `cleanup_fb`. The<br /> opposite can also be true.<br /> <br /> In fact, the struct drm_plane .state shouldn&amp;#39;t be accessed directly<br /> but instead, the `drm_atomic_get_new_plane_state()` helper function should<br /> be used. So, we could stick to this check, but using<br /> `drm_atomic_get_new_plane_state()`. But actually, this check is not re<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btintel: Fix null ptr deref in btintel_read_version<br /> <br /> If hci_cmd_sync_complete() is triggered and skb is NULL, then<br /> hdev-&gt;req_skb is NULL, which will cause this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()<br /> <br /> Many syzbot reports show extreme rtnl pressure, and many of them hint<br /> that smc acquires rtnl in netns creation for no good reason [1]<br /> <br /> This patch returns early from smc_pnet_net_init()<br /> if there is no netdevice yet.<br /> <br /> I am not even sure why smc_pnet_create_pnetids_list() even exists,<br /> because smc_pnet_netdev_event() is also calling<br /> smc_pnet_add_base_pnetid() when handling NETDEV_UP event.<br /> <br /> [1] extract of typical syzbot reports<br /> <br /> 2 locks held by syz-executor.3/12252:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12253:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12257:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12261:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.0/12265:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.3/12268:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.4/12271:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.1/12274:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878<br /> 2 locks held by syz-executor.2/12280:<br /> #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]<br /> #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: send: handle path ref underflow in header iterate_inode_ref()<br /> <br /> Change BUG_ON to proper error handling if building the path buffer<br /> fails. The pointers are not printed so we don&amp;#39;t accidentally leak kernel<br /> addresses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()<br /> <br /> The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,<br /> as it could be caused only by two impossible conditions:<br /> <br /> - at first the search key is set up to look for a chunk tree item, with<br /> offset -1, this is an inexact search and the key-&gt;offset will contain<br /> the correct offset upon a successful search, a valid chunk tree item<br /> cannot have an offset -1<br /> <br /> - after first successful search, the found_key corresponds to a chunk<br /> item, the offset is decremented by 1 before the next loop, it&amp;#39;s<br /> impossible to find a chunk item there due to alignment and size<br /> constraints

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: check A-MSDU format more carefully<br /> <br /> If it looks like there&amp;#39;s another subframe in the A-MSDU<br /> but the header isn&amp;#39;t fully there, we can end up reading<br /> data out of bounds, only to discard later. Make this a<br /> bit more careful and check if the subframe header can<br /> even be present.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: decrease MHI channel buffer length to 8KB<br /> <br /> Currently buf_len field of ath11k_mhi_config_qca6390 is assigned<br /> with 0, making MHI use a default size, 64KB, to allocate channel<br /> buffers. This is likely to fail in some scenarios where system<br /> memory is highly fragmented and memory compaction or reclaim is<br /> not allowed.<br /> <br /> There is a fail report which is caused by it:<br /> kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0<br /> CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb<br /> Workqueue: events_unbound async_run_entry_fn<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x47/0x60<br /> warn_alloc+0x13a/0x1b0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __alloc_pages_direct_compact+0xab/0x210<br /> __alloc_pages_slowpath.constprop.0+0xd3e/0xda0<br /> __alloc_pages+0x32d/0x350<br /> ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> __kmalloc_large_node+0x72/0x110<br /> __kmalloc+0x37c/0x480<br /> ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> device_for_each_child+0x5c/0xa0<br /> ? __pfx_pci_pm_resume+0x10/0x10<br /> ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> dpm_run_callback+0x8c/0x1e0<br /> device_resume+0x104/0x340<br /> ? __pfx_dpm_watchdog_handler+0x10/0x10<br /> async_resume+0x1d/0x30<br /> async_run_entry_fn+0x32/0x120<br /> process_one_work+0x168/0x330<br /> worker_thread+0x2f5/0x410<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe8/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Actually those buffers are used only by QMI target -&gt; host communication.<br /> And for WCN6855 and QCA6390, the largest packet size for that is less<br /> than 6KB. So change buf_len field to 8KB, which results in order 1<br /> allocation if page size is 4KB. In this way, we can at least save some<br /> memory, and as well as decrease the possibility of allocation failure<br /> in those scenarios.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-direct: Leak pages on dma_set_decrypted() failure<br /> <br /> On TDX it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> DMA could free decrypted/shared pages if dma_set_decrypted() fails. This<br /> should be a rare case. Just leak the pages in this case instead of<br /> freeing them.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/zone: Add a null pointer check to the psz_kmsg_read<br /> <br /> kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: skbuff: add overflow debug check to pull/push helpers<br /> <br /> syzbot managed to trigger following splat:<br /> BUG: KASAN: use-after-free in __skb_flow_dissect+0x4a3b/0x5e50<br /> Read of size 1 at addr ffff888208a4000e by task a.out/2313<br /> [..]<br /> __skb_flow_dissect+0x4a3b/0x5e50<br /> __skb_get_hash+0xb4/0x400<br /> ip_tunnel_xmit+0x77e/0x26f0<br /> ipip_tunnel_xmit+0x298/0x410<br /> ..<br /> <br /> Analysis shows that the skb has a valid -&gt;head, but bogus -&gt;data<br /> pointer.<br /> <br /> skb-&gt;data gets its bogus value via the neigh layer, which does:<br /> <br /> 1556 __skb_pull(skb, skb_network_offset(skb));<br /> <br /> ... and the skb was already dodgy at this point:<br /> <br /> skb_network_offset(skb) returns a negative value due to an<br /> earlier overflow of skb-&gt;network_header (u16). __skb_pull thus<br /> "adjusts" skb-&gt;data by a huge offset, pointing outside skb-&gt;head<br /> area.<br /> <br /> Allow debug builds to splat when we try to pull/push more than<br /> INT_MAX bytes.<br /> <br /> After this, the syzkaller reproducer yields a more precise splat<br /> before the flow dissector attempts to read off skb-&gt;data memory:<br /> <br /> WARNING: CPU: 5 PID: 2313 at include/linux/skbuff.h:2653 neigh_connected_output+0x28e/0x400<br /> ip_finish_output2+0xb25/0xed0<br /> iptunnel_xmit+0x4ff/0x870<br /> ipgre_xmit+0x78e/0xbb0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain<br /> <br /> According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of<br /> hdmi rx verification IP that should not enable for HDMI TX.<br /> But actually if the clock is disabled before HDMI/LCDIF probe,<br /> LCDIF will not get pixel clock from HDMI PHY and print the error<br /> logs:<br /> <br /> [CRTC:39:crtc-2] vblank wait timed out<br /> WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260<br /> <br /> Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: ti: Add a null pointer check to the omap_prm_domain_init<br /> <br /> devm_kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.