Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: TC, Fix internal port memory leak<br /> <br /> The flow rule can be splited, and the extra post_act rules are added<br /> to post_act table. It&amp;#39;s possible to trigger memleak when the rule<br /> forwards packets from internal port and over tunnel, in the case that,<br /> for example, CT &amp;#39;new&amp;#39; state offload is allowed. As int_port object is<br /> assigned to the flow attribute of post_act rule, and its refcnt is<br /> incremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() is<br /> not called, the refcnt is never decremented, then int_port is never<br /> freed.<br /> <br /> The kmemleak reports the following error:<br /> unreferenced object 0xffff888128204b80 (size 64):<br /> comm "handler20", pid 50121, jiffies 4296973009 (age 642.932s)<br /> hex dump (first 32 bytes):<br /> 01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00 ................<br /> 98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff .wgA.....wgA....<br /> backtrace:<br /> [] kmalloc_trace+0x27/0x120<br /> [] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core]<br /> [] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core]<br /> [] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core]<br /> [] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core]<br /> [] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core]<br /> [] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core]<br /> [] tc_setup_cb_add+0x1cf/0x410<br /> [] fl_hw_replace_filter+0x38f/0x670 [cls_flower]<br /> [] fl_change+0x1fd5/0x4430 [cls_flower]<br /> [] tc_new_tfilter+0x867/0x2010<br /> [] rtnetlink_rcv_msg+0x6fc/0x9f0<br /> [] netlink_rcv_skb+0x12c/0x360<br /> [] netlink_unicast+0x438/0x710<br /> [] netlink_sendmsg+0x794/0xc50<br /> [] sock_sendmsg+0xc5/0x190<br /> <br /> So fix this by moving int_port cleanup code to the flow attribute<br /> free helper, which is used by all the attribute free cases.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: hns3: fix deadlock issue when externel_lb and reset are executed together<br /> <br /> When externel_lb and reset are executed together, a deadlock may<br /> occur:<br /> [ 3147.217009] INFO: task kworker/u321:0:7 blocked for more than 120 seconds.<br /> [ 3147.230483] "echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this message.<br /> [ 3147.238999] task:kworker/u321:0 state:D stack: 0 pid: 7 ppid: 2 flags:0x00000008<br /> [ 3147.248045] Workqueue: hclge hclge_service_task [hclge]<br /> [ 3147.253957] Call trace:<br /> [ 3147.257093] __switch_to+0x7c/0xbc<br /> [ 3147.261183] __schedule+0x338/0x6f0<br /> [ 3147.265357] schedule+0x50/0xe0<br /> [ 3147.269185] schedule_preempt_disabled+0x18/0x24<br /> [ 3147.274488] __mutex_lock.constprop.0+0x1d4/0x5dc<br /> [ 3147.279880] __mutex_lock_slowpath+0x1c/0x30<br /> [ 3147.284839] mutex_lock+0x50/0x60<br /> [ 3147.288841] rtnl_lock+0x20/0x2c<br /> [ 3147.292759] hclge_reset_prepare+0x68/0x90 [hclge]<br /> [ 3147.298239] hclge_reset_subtask+0x88/0xe0 [hclge]<br /> [ 3147.303718] hclge_reset_service_task+0x84/0x120 [hclge]<br /> [ 3147.309718] hclge_service_task+0x2c/0x70 [hclge]<br /> [ 3147.315109] process_one_work+0x1d0/0x490<br /> [ 3147.319805] worker_thread+0x158/0x3d0<br /> [ 3147.324240] kthread+0x108/0x13c<br /> [ 3147.328154] ret_from_fork+0x10/0x18<br /> <br /> In externel_lb process, the hns3 driver call napi_disable()<br /> first, then the reset happen, then the restore process of the<br /> externel_lb will fail, and will not call napi_enable(). When<br /> doing externel_lb again, napi_disable() will be double call,<br /> cause a deadlock of rtnl_lock().<br /> <br /> This patch use the HNS3_NIC_STATE_DOWN state to protect the<br /> calling of napi_disable() and napi_enable() in externel_lb<br /> process, just as the usage in ndo_stop() and ndo_start().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg()<br /> <br /> syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for<br /> ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with<br /> pkt_len = 0 but ath9k_hif_usb_rx_stream() uses<br /> __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that<br /> pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb<br /> with uninitialized memory and ath9k_htc_rx_msg() is reading from<br /> uninitialized memory.<br /> <br /> Since bytes accessed by ath9k_htc_rx_msg() is not known until<br /> ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid<br /> pkt_len at "if (pkt_len &gt; 2 * MAX_RX_BUF_SIZE) {" line in<br /> ath9k_hif_usb_rx_stream().<br /> <br /> We have two choices. One is to workaround by adding __GFP_ZERO so that<br /> ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let<br /> ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose<br /> the latter.<br /> <br /> Note that I&amp;#39;m not sure threshold condition is correct, for I can&amp;#39;t find<br /> details on possible packet length used by this protocol.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: set tx_tstamps when creating new Tx rings via ethtool<br /> <br /> When the user changes the number of queues via ethtool, the driver<br /> allocates new rings. This allocation did not initialize tx_tstamps. This<br /> results in the tx_tstamps field being zero (due to kcalloc allocation), and<br /> would result in a NULL pointer dereference when attempting a transmit<br /> timestamp on the new ring.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: mtk_eth_soc: fix possible memory leak in mtk_probe()<br /> <br /> If mtk_wed_add_hw() has been called, mtk_wed_exit() needs be called<br /> in error path or removing module to free the memory allocated in<br /> mtk_wed_add_hw().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix potential use-after-free bug when trimming caps<br /> <br /> When trimming the caps and just after the &amp;#39;session-&gt;s_cap_lock&amp;#39; is<br /> released in ceph_iterate_session_caps() the cap maybe removed by<br /> another thread, and when using the stale cap memory in the callbacks<br /> it will trigger use-after-free crash.<br /> <br /> We need to check the existence of the cap just after the &amp;#39;ci-&gt;i_ceph_lock&amp;#39;<br /> being acquired. And do nothing if it&amp;#39;s already removed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mips: bmips: BCM6358: disable RAC flush for TP1<br /> <br /> RAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:<br /> [ 3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform<br /> [ 3.895011] Reserved instruction in kernel code[#1]:<br /> [ 3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0<br /> [ 3.905829] $ 0 : 00000000 10008700 00000000 77d94060<br /> [ 3.911238] $ 4 : 7fd1f088 00000000 81431cac 81431ca0<br /> [ 3.916641] $ 8 : 00000000 ffffefff 8075cd34 00000000<br /> [ 3.922043] $12 : 806f8d40 f3e812b7 00000000 000d9aaa<br /> [ 3.927446] $16 : 7fd1f068 7fd1f080 7ff559b8 81428470<br /> [ 3.932848] $20 : 00000000 00000000 55590000 77d70000<br /> [ 3.938251] $24 : 00000018 00000010<br /> [ 3.943655] $28 : 81430000 81431e60 81431f28 800157fc<br /> [ 3.949058] Hi : 00000000<br /> [ 3.952013] Lo : 00000000<br /> [ 3.955019] epc : 80015808 setup_sigcontext+0x54/0x24c<br /> [ 3.960464] ra : 800157fc setup_sigcontext+0x48/0x24c<br /> [ 3.965913] Status: 10008703 KERNEL EXL IE<br /> [ 3.970216] Cause : 00800028 (ExcCode 0a)<br /> [ 3.974340] PrId : 0002a010 (Broadcom BMIPS4350)<br /> [ 3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common<br /> [ 3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)<br /> [ 4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470<br /> [ 4.009467] 81431f28 7fd1f080 55590000 77d70000 77d5498c 80015c70 806f0000 8063ae74<br /> [ 4.018149] 08100002 81431f28 0000000a 08100002 81431f28 0000000a 77d6b418 00000003<br /> [ 4.026831] ffffffff 80016414 80080734 81431ecc 81431ecc 00000001 00000000 04000000<br /> [ 4.035512] 77d54874 00000000 00000000 00000000 00000000 00000012 00000002 00000000<br /> [ 4.044196] ...<br /> [ 4.046706] Call Trace:<br /> [ 4.049238] [] setup_sigcontext+0x54/0x24c<br /> [ 4.054356] [] setup_frame+0xdc/0x124<br /> [ 4.059015] [] do_notify_resume+0x1dc/0x288<br /> [ 4.064207] [] work_notifysig+0x10/0x18<br /> [ 4.069036]<br /> [ 4.070538] Code: 8fc300b4 00001025 26240008 ac830004 3c048063 0c0228aa 24846a00 26240010<br /> [ 4.080686]<br /> [ 4.082517] ---[ end trace 22a8edb41f5f983b ]---<br /> [ 4.087374] Kernel panic - not syncing: Fatal exception<br /> [ 4.092753] Rebooting in 1 seconds..<br /> <br /> Because the bootloader (CFE) is not initializing the Read-ahead cache properly<br /> on the second thread (TP1). Since the RAC was not initialized properly, we<br /> should avoid flushing it at the risk of corrupting the instruction stream as<br /> seen in the trace above.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ping: Fix potentail NULL deref for /proc/net/icmp.<br /> <br /> After commit dbca1596bbb0 ("ping: convert to RCU lookups, get rid<br /> of rwlock"), we use RCU for ping sockets, but we should use spinlock<br /> for /proc/net/icmp to avoid a potential NULL deref mentioned in<br /> the previous patch.<br /> <br /> Let&amp;#39;s go back to using spinlock there.<br /> <br /> Note we can convert ping sockets to use hlist instead of hlist_nulls<br /> because we do not use SLAB_TYPESAFE_BY_RCU for ping sockets.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Fix slab-out-of-bounds read in hdr_delete_de()<br /> <br /> Here is a BUG report from syzbot:<br /> <br /> BUG: KASAN: slab-out-of-bounds in hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806<br /> Read of size 16842960 at addr ffff888079cc0600 by task syz-executor934/3631<br /> <br /> Call Trace:<br /> memmove+0x25/0x60 mm/kasan/shadow.c:54<br /> hdr_delete_de+0xe0/0x150 fs/ntfs3/index.c:806<br /> indx_delete_entry+0x74f/0x3670 fs/ntfs3/index.c:2193<br /> ni_remove_name+0x27a/0x980 fs/ntfs3/frecord.c:2910<br /> ntfs_unlink_inode+0x3d4/0x720 fs/ntfs3/inode.c:1712<br /> ntfs_rename+0x41a/0xcb0 fs/ntfs3/namei.c:276<br /> <br /> Before using the meta-data in struct INDEX_HDR, we need to<br /> check index header valid or not. Otherwise, the corruptedi<br /> (or malicious) fs image can cause out-of-bounds access which<br /> could make kernel panic.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: mm: fix VA-range sanity check<br /> <br /> Both create_mapping_noalloc() and update_mapping_prot() sanity-check<br /> their &amp;#39;virt&amp;#39; parameter, but the check itself doesn&amp;#39;t make much sense.<br /> The condition used today appears to be a historical accident.<br /> <br /> The sanity-check condition:<br /> <br /> if ((virt &gt;= PAGE_END) &amp;&amp; (virt

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SMB3: Add missing locks to protect deferred close file list<br /> <br /> cifs_del_deferred_close function has a critical section which modifies<br /> the deferred close file list. We must acquire deferred_lock before<br /> calling cifs_del_deferred_close function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: enable use of both GFP_KERNEL and GFP_ATOMIC in convert_context()<br /> <br /> The following warning was triggered on a hardware environment:<br /> <br /> SELinux: Converting 162 SID table entries...<br /> BUG: sleeping function called from invalid context at<br /> __might_sleep+0x60/0x74 0x0<br /> in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 5943, name: tar<br /> CPU: 7 PID: 5943 Comm: tar Tainted: P O 5.10.0 #1<br /> Call trace:<br /> dump_backtrace+0x0/0x1c8<br /> show_stack+0x18/0x28<br /> dump_stack+0xe8/0x15c<br /> ___might_sleep+0x168/0x17c<br /> __might_sleep+0x60/0x74<br /> __kmalloc_track_caller+0xa0/0x7dc<br /> kstrdup+0x54/0xac<br /> convert_context+0x48/0x2e4<br /> sidtab_context_to_sid+0x1c4/0x36c<br /> security_context_to_sid_core+0x168/0x238<br /> security_context_to_sid_default+0x14/0x24<br /> inode_doinit_use_xattr+0x164/0x1e4<br /> inode_doinit_with_dentry+0x1c0/0x488<br /> selinux_d_instantiate+0x20/0x34<br /> security_d_instantiate+0x70/0xbc<br /> d_splice_alias+0x4c/0x3c0<br /> ext4_lookup+0x1d8/0x200 [ext4]<br /> __lookup_slow+0x12c/0x1e4<br /> walk_component+0x100/0x200<br /> path_lookupat+0x88/0x118<br /> filename_lookup+0x98/0x130<br /> user_path_at_empty+0x48/0x60<br /> vfs_statx+0x84/0x140<br /> vfs_fstatat+0x20/0x30<br /> __se_sys_newfstatat+0x30/0x74<br /> __arm64_sys_newfstatat+0x1c/0x2c<br /> el0_svc_common.constprop.0+0x100/0x184<br /> do_el0_svc+0x1c/0x2c<br /> el0_svc+0x20/0x34<br /> el0_sync_handler+0x80/0x17c<br /> el0_sync+0x13c/0x140<br /> SELinux: Context system_u:object_r:pssp_rsyslog_log_t:s0:c0 is<br /> not valid (left unmapped).<br /> <br /> It was found that within a critical section of spin_lock_irqsave in<br /> sidtab_context_to_sid(), convert_context() (hooked by<br /> sidtab_convert_params.func) might cause the process to sleep via<br /> allocating memory with GFP_KERNEL, which is problematic.<br /> <br /> As Ondrej pointed out [1], convert_context()/sidtab_convert_params.func<br /> has another caller sidtab_convert_tree(), which is okay with GFP_KERNEL.<br /> Therefore, fix this problem by adding a gfp_t argument for<br /> convert_context()/sidtab_convert_params.func and pass GFP_KERNEL/_ATOMIC<br /> properly in individual callers.<br /> <br /> [PM: wrap long BUG() output lines, tweak subject line]