Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: fix use-after-free in cmp_bss()<br /> <br /> Following bss_free() quirk introduced in commit 776b3580178f<br /> ("cfg80211: track hidden SSID networks properly"), adjust<br /> cfg80211_update_known_bss() to free the last beacon frame<br /> elements only if they&amp;#39;re not shared via the corresponding<br /> &amp;#39;hidden_beacon_bss&amp;#39; pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: fix NULL pointer dereference in tee_shm_put<br /> <br /> tee_shm_put have NULL pointer dereference:<br /> <br /> __optee_disable_shm_cache --&gt;<br /> shm = reg_pair_to_ptr(...);//shm maybe return NULL<br /> tee_shm_free(shm); --&gt;<br /> tee_shm_put(shm);//crash<br /> <br /> Add check in tee_shm_put to fix it.<br /> <br /> panic log:<br /> Unable to handle kernel paging request at virtual address 0000000000100cca<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000<br /> [0000000000100cca] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 0000000096000004 [#1] SMP<br /> CPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----<br /> 6.6.0-39-generic #38<br /> Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07<br /> Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.0<br /> 10/26/2022<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : tee_shm_put+0x24/0x188<br /> lr : tee_shm_free+0x14/0x28<br /> sp : ffff001f98f9faf0<br /> x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000<br /> x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048<br /> x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88<br /> x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffff<br /> x17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003<br /> x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101<br /> x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0c<br /> x8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100cca<br /> Call trace:<br /> tee_shm_put+0x24/0x188<br /> tee_shm_free+0x14/0x28<br /> __optee_disable_shm_cache+0xa8/0x108<br /> optee_shutdown+0x28/0x38<br /> platform_shutdown+0x28/0x40<br /> device_shutdown+0x144/0x2b0<br /> kernel_power_off+0x3c/0x80<br /> hibernate+0x35c/0x388<br /> state_store+0x64/0x80<br /> kobj_attr_store+0x14/0x28<br /> sysfs_kf_write+0x48/0x60<br /> kernfs_fop_write_iter+0x128/0x1c0<br /> vfs_write+0x270/0x370<br /> ksys_write+0x6c/0x100<br /> __arm64_sys_write+0x20/0x30<br /> invoke_syscall+0x4c/0x120<br /> el0_svc_common.constprop.0+0x44/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x24/0x88<br /> el0t_64_sync_handler+0x134/0x150<br /> el0t_64_sync+0x14c/0x15

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: writeback: fix use-after-free in __mark_inode_dirty()<br /> <br /> An use-after-free issue occurred when __mark_inode_dirty() get the<br /> bdi_writeback that was in the progress of switching.<br /> <br /> CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1<br /> ......<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : __mark_inode_dirty+0x124/0x418<br /> lr : __mark_inode_dirty+0x118/0x418<br /> sp : ffffffc08c9dbbc0<br /> ........<br /> Call trace:<br /> __mark_inode_dirty+0x124/0x418<br /> generic_update_time+0x4c/0x60<br /> file_modified+0xcc/0xd0<br /> ext4_buffered_write_iter+0x58/0x124<br /> ext4_file_write_iter+0x54/0x704<br /> vfs_write+0x1c0/0x308<br /> ksys_write+0x74/0x10c<br /> __arm64_sys_write+0x1c/0x28<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0xc0/0xe0<br /> do_el0_svc+0x1c/0x28<br /> el0_svc+0x40/0xe4<br /> el0t_64_sync_handler+0x120/0x12c<br /> el0t_64_sync+0x194/0x198<br /> <br /> Root cause is:<br /> <br /> systemd-random-seed kworker<br /> ----------------------------------------------------------------------<br /> ___mark_inode_dirty inode_switch_wbs_work_fn<br /> <br /> spin_lock(&amp;inode-&gt;i_lock);<br /> inode_attach_wb<br /> locked_inode_to_wb_and_lock_list<br /> get inode-&gt;i_wb<br /> spin_unlock(&amp;inode-&gt;i_lock);<br /> spin_lock(&amp;wb-&gt;list_lock)<br /> spin_lock(&amp;inode-&gt;i_lock)<br /> inode_io_list_move_locked<br /> spin_unlock(&amp;wb-&gt;list_lock)<br /> spin_unlock(&amp;inode-&gt;i_lock)<br /> spin_lock(&amp;old_wb-&gt;list_lock)<br /> inode_do_switch_wbs<br /> spin_lock(&amp;inode-&gt;i_lock)<br /> inode-&gt;i_wb = new_wb<br /> spin_unlock(&amp;inode-&gt;i_lock)<br /> spin_unlock(&amp;old_wb-&gt;list_lock)<br /> wb_put_many(old_wb, nr_switched)<br /> cgwb_release<br /> old wb released<br /> wb_wakeup_delayed() accesses wb,<br /> then trigger the use-after-free<br /> issue<br /> <br /> Fix this race condition by holding inode spinlock until<br /> wb_wakeup_delayed() finished.

*** Pendiente de traducción *** CMSEasy v7.7.8.0 and before is vulnerable to Arbitrary file deletion in database_admin.php.

*** Pendiente de traducción *** Directory traversal vulnerability in Sync In server thru 1.1.1 allowing authenticated attackers to gain read and write access to the system via FilesManager.saveMultipart function in backend/src/applications/files/services/files-manager.service.ts, and FilesManager.compress function in backend/src/applications/files/services/files-manager.service.ts.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6<br /> <br /> When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just<br /> exits the function. This ends up causing a memory-leak:<br /> <br /> unreferenced object 0xffff0000281a8200 (size 2496):<br /> comm "softirq", pid 0, jiffies 4295174684<br /> hex dump (first 32 bytes):<br /> 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................<br /> 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............<br /> backtrace (crc 5ebdbe15):<br /> kmemleak_alloc+0x44/0xe0<br /> kmem_cache_alloc_noprof+0x248/0x470<br /> sk_prot_alloc+0x48/0x120<br /> sk_clone_lock+0x38/0x3b0<br /> inet_csk_clone_lock+0x34/0x150<br /> tcp_create_openreq_child+0x3c/0x4a8<br /> tcp_v6_syn_recv_sock+0x1c0/0x620<br /> tcp_check_req+0x588/0x790<br /> tcp_v6_rcv+0x5d0/0xc18<br /> ip6_protocol_deliver_rcu+0x2d8/0x4c0<br /> ip6_input_finish+0x74/0x148<br /> ip6_input+0x50/0x118<br /> ip6_sublist_rcv+0x2fc/0x3b0<br /> ipv6_list_rcv+0x114/0x170<br /> __netif_receive_skb_list_core+0x16c/0x200<br /> netif_receive_skb_list_internal+0x1f0/0x2d0<br /> <br /> This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when<br /> exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need<br /> to be called. They make sure the newsk will end up being correctly<br /> free&amp;#39;d.<br /> <br /> tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit<br /> label that takes care of things. So, this patch here makes sure<br /> tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar<br /> error-handling and thus fixes the leak for TCP-AO.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix potential invalid access when MAC list is empty<br /> <br /> list_first_entry() never returns NULL - if the list is empty, it still<br /> returns a pointer to an invalid object, leading to potential invalid<br /> memory access when dereferenced.<br /> <br /> Fix this by using list_first_entry_or_null instead of list_first_entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL access of tx-&gt;in_use in ice_ll_ts_intr<br /> <br /> Recent versions of the E810 firmware have support for an extra interrupt to<br /> handle report of the "low latency" Tx timestamps coming from the<br /> specialized low latency firmware interface. Instead of polling the<br /> registers, software can wait until the low latency interrupt is fired.<br /> <br /> This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as<br /> it uses the same "ready" bitmap to track which Tx timestamps complete.<br /> <br /> Unfortunately, the ice_ll_ts_intr() function does not check if the<br /> tracker is initialized before its first access. This results in NULL<br /> dereference or use-after-free bugs similar to the issues fixed in the<br /> ice_ptp_ts_irq() function.<br /> <br /> Fix this by only checking the in_use bitmap (and other fields) if the<br /> tracker is marked as initialized. The reset flow will clear the init field<br /> under lock before it tears the tracker down, thus preventing any<br /> use-after-free or NULL access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL access of tx-&gt;in_use in ice_ptp_ts_irq<br /> <br /> The E810 device has support for a "low latency" firmware interface to<br /> access and read the Tx timestamps. This interface does not use the standard<br /> Tx timestamp logic, due to the latency overhead of proxying sideband<br /> command requests over the firmware AdminQ.<br /> <br /> The logic still makes use of the Tx timestamp tracking structure,<br /> ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx<br /> timestamps complete.<br /> <br /> Unfortunately, the ice_ptp_ts_irq() function does not check if the tracker<br /> is initialized before its first access. This results in NULL dereference or<br /> use-after-free bugs similar to the following:<br /> <br /> [245977.278756] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [245977.278774] RIP: 0010:_find_first_bit+0x19/0x40<br /> [245977.278796] Call Trace:<br /> [245977.278809] ? ice_misc_intr+0x364/0x380 [ice]<br /> <br /> This can occur if a Tx timestamp interrupt races with the driver reset<br /> logic.<br /> <br /> Fix this by only checking the in_use bitmap (and other fields) if the<br /> tracker is marked as initialized. The reset flow will clear the init field<br /> under lock before it tears the tracker down, thus preventing any<br /> use-after-free or NULL access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw-nuss: Fix null pointer dereference for ndev<br /> <br /> In the TX completion packet stage of TI SoCs with CPSW2G instance, which<br /> has single external ethernet port, ndev is accessed without being<br /> initialized if no TX packets have been processed. It results into null<br /> pointer dereference, causing kernel to crash. Fix this by having a check<br /> on the number of TX packets which have been processed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000002ec<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc]<br /> ...<br /> Call Trace:<br /> <br /> smcr_buf_map_link+0x211/0x2a0 [smc]<br /> __smc_buf_create+0x522/0x970 [smc]<br /> smc_buf_create+0x3a/0x110 [smc]<br /> smc_find_rdma_v2_device_serv+0x18f/0x240 [smc]<br /> ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc]<br /> smc_listen_find_device+0x1dd/0x2b0 [smc]<br /> smc_listen_work+0x30f/0x580 [smc]<br /> process_one_work+0x18c/0x340<br /> worker_thread+0x242/0x360<br /> kthread+0xe7/0x220<br /> ret_from_fork+0x13a/0x160<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> If the software RoCE device is used, ibdev-&gt;dma_device is a null pointer.<br /> As a result, the problem occurs. Null pointer detection is added to<br /> prevent problems.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: mlx4: Fix IS_ERR() vs NULL check bug in mlx4_en_create_rx_ring<br /> <br /> Replace NULL check with IS_ERR() check after calling page_pool_create()<br /> since this function returns error pointers (ERR_PTR).<br /> Using NULL check could lead to invalid pointer dereference.