Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: Disallow unallocated resources to be returned<br /> <br /> In the event that the topology requests resources that have not been<br /> created by the system (because they are typically not represented in<br /> dpu_mdss_cfg ^1), the resource(s) in global_state (in this case DSC<br /> blocks, until their allocation/assignment is being sanity-checked in<br /> "drm/msm/dpu: Reject topologies for which no DSC blocks are available")<br /> remain NULL but will still be returned out of<br /> dpu_rm_get_assigned_resources, where the caller expects to get an array<br /> containing num_blks valid pointers (but instead gets these NULLs).<br /> <br /> To prevent this from happening, where null-pointer dereferences<br /> typically result in a hard-to-debug platform lockup, num_blks shouldn&amp;#39;t<br /> increase past NULL blocks and will print an error and break instead.<br /> After all, max_blks represents the static size of the maximum number of<br /> blocks whereas the actual amount varies per platform.<br /> <br /> ^1: which can happen after a git rebase ended up moving additions to<br /> _dpu_cfg to a different struct which has the same patch context.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/517636/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: ocb: don&amp;#39;t leave if not joined<br /> <br /> If there&amp;#39;s no OCB state, don&amp;#39;t ask the driver/mac80211 to<br /> leave, since that&amp;#39;s just confusing. Since set/clear the<br /> chandef state, that&amp;#39;s a simple check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/DOE: Fix memory leak with CONFIG_DEBUG_OBJECTS=y<br /> <br /> After a pci_doe_task completes, its work_struct needs to be destroyed<br /> to avoid a memory leak with CONFIG_DEBUG_OBJECTS=y.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: remove WARN_ON to prevent panic_on_warn<br /> <br /> Remove unnecessary early code development check and the WARN_ON<br /> that it uses. The irq alloc and free paths have long been<br /> cleaned up and this check shouldn&amp;#39;t have stuck around so long.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix one memleak in __inet_del_ifa()<br /> <br /> I got the below warning when do fuzzing test:<br /> unregister_netdevice: waiting for bond0 to become free. Usage count = 2<br /> <br /> It can be repoduced via:<br /> <br /> ip link add bond0 type bond<br /> sysctl -w net.ipv4.conf.bond0.promote_secondaries=1<br /> ip addr add 4.117.174.103/0 scope 0x40 dev bond0<br /> ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0<br /> ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0<br /> ip addr del 4.117.174.103/0 scope 0x40 dev bond0<br /> ip link delete bond0 type bond<br /> <br /> In this reproduction test case, an incorrect &amp;#39;last_prim&amp;#39; is found in<br /> __inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)<br /> is lost. The memory of the secondary address is leaked and the reference of<br /> in_device and net_device is leaked.<br /> <br /> Fix this problem:<br /> Look for &amp;#39;last_prim&amp;#39; starting at location of the deleted IP and inserting<br /> the promoted IP into the location of &amp;#39;last_prim&amp;#39;.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/sev: Make enc_dec_hypercall() accept a size instead of npages<br /> <br /> enc_dec_hypercall() accepted a page count instead of a size, which<br /> forced its callers to round up. As a result, non-page aligned<br /> vaddrs caused pages to be spuriously marked as decrypted via the<br /> encryption status hypercall, which in turn caused consistent<br /> corruption of pages during live migration. Live migration requires<br /> accurate encryption status information to avoid migrating pages<br /> from the wrong perspective.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: of: fix double-free on unregistration<br /> <br /> Since commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermal<br /> zone parameters structure"), thermal_zone_device_register() allocates<br /> a copy of the tzp argument and frees it when unregistering, so<br /> thermal_of_zone_register() now ends up leaking its original tzp and<br /> double-freeing the tzp copy. Fix this by locating tzp on stack instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: virtio - Fix race on data_avail and actual data<br /> <br /> The virtio rng device kicks off a new entropy request whenever the<br /> data available reaches zero. When a new request occurs at the end<br /> of a read operation, that is, when the result of that request is<br /> only needed by the next reader, then there is a race between the<br /> writing of the new data and the next reader.<br /> <br /> This is because there is no synchronisation whatsoever between the<br /> writer and the reader.<br /> <br /> Fix this by writing data_avail with smp_store_release and reading<br /> it with smp_load_acquire when we first enter read. The subsequent<br /> reads are safe because they&amp;#39;re either protected by the first load<br /> acquire, or by the completion mechanism.<br /> <br /> Also remove the redundant zeroing of data_idx in random_recv_done<br /> (data_idx must already be zero at this point) and data_avail in<br /> request_entropy (ditto).

*** 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.