Vulnerabilidades

*** Pendiente de traducción *** A security flaw has been discovered in fuyang_lipengjun platform 1.0. This impacts the function AttributeController of the file /attribute/queryAll. Performing manipulation results in improper authorization. Remote exploitation of the attack is possible. The exploit has been released to the public and may be exploited.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: don&amp;#39;t reset unchangable mount option in f2fs_remount()<br /> <br /> syzbot reports a bug as below:<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN<br /> RIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942<br /> Call Trace:<br /> lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691<br /> __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline]<br /> _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300<br /> __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100<br /> f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116<br /> f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664<br /> f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838<br /> vfs_fallocate+0x54b/0x6b0 fs/open.c:324<br /> ksys_fallocate fs/open.c:347 [inline]<br /> __do_sys_fallocate fs/open.c:355 [inline]<br /> __se_sys_fallocate fs/open.c:353 [inline]<br /> __x64_sys_fallocate+0xbd/0x100 fs/open.c:353<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The root cause is race condition as below:<br /> - since it tries to remount rw filesystem, so that do_remount won&amp;#39;t<br /> call sb_prepare_remount_readonly to block fallocate, there may be race<br /> condition in between remount and fallocate.<br /> - in f2fs_remount(), default_options() will reset mount option to default<br /> one, and then update it based on result of parse_options(), so there is<br /> a hole which race condition can happen.<br /> <br /> Thread A Thread B<br /> - f2fs_fill_super<br /> - parse_options<br /> - clear_opt(READ_EXTENT_CACHE)<br /> <br /> - f2fs_remount<br /> - default_options<br /> - set_opt(READ_EXTENT_CACHE)<br /> - f2fs_fallocate<br /> - f2fs_insert_range<br /> - f2fs_drop_extent_tree<br /> - __drop_extent_tree<br /> - __may_extent_tree<br /> - test_opt(READ_EXTENT_CACHE) return true<br /> - write_lock(&amp;et-&gt;lock) access NULL pointer<br /> - parse_options<br /> - clear_opt(READ_EXTENT_CACHE)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: skb_partial_csum_set() fix against transport header magic value<br /> <br /> skb-&gt;transport_header uses the special 0xFFFF value<br /> to mark if the transport header was set or not.<br /> <br /> We must prevent callers to accidentaly set skb-&gt;transport_header<br /> to 0xFFFF. Note that only fuzzers can possibly do this today.<br /> <br /> syzbot reported:<br /> <br /> WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline]<br /> WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103<br /> Modules linked in:<br /> CPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023<br /> RIP: 0010:skb_transport_header include/linux/skbuff.h:2847 [inline]<br /> RIP: 0010:skb_transport_offset include/linux/skbuff.h:2956 [inline]<br /> RIP: 0010:virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103<br /> Code: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f<br /> RSP: 0018:ffffc90004497880 EFLAGS: 00010293<br /> RAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100<br /> RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff<br /> RBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034<br /> R10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8<br /> R13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35<br /> FS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> packet_snd net/packet/af_packet.c:3076 [inline]<br /> packet_sendmsg+0x4590/0x61a0 net/packet/af_packet.c:3115<br /> sock_sendmsg_nosec net/socket.c:724 [inline]<br /> sock_sendmsg net/socket.c:747 [inline]<br /> __sys_sendto+0x472/0x630 net/socket.c:2144<br /> __do_sys_sendto net/socket.c:2156 [inline]<br /> __se_sys_sendto net/socket.c:2152 [inline]<br /> __x64_sys_sendto+0xe5/0x100 net/socket.c:2152<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f9210c8c169<br /> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f9211a59168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169<br /> RDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003<br /> RBP: 00007f9210ce7ca1 R08: 0000000020000540 R09: 0000000000000014<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffe135d65cf R14: 00007f9211a59300 R15: 0000000000022000

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix sysfs interface lifetime<br /> <br /> The current nilfs2 sysfs support has issues with the timing of creation<br /> and deletion of sysfs entries, potentially leading to null pointer<br /> dereferences, use-after-free, and lockdep warnings.<br /> <br /> Some of the sysfs attributes for nilfs2 per-filesystem instance refer to<br /> metadata file "cpfile", "sufile", or "dat", but<br /> nilfs_sysfs_create_device_group that creates those attributes is executed<br /> before the inodes for these metadata files are loaded, and<br /> nilfs_sysfs_delete_device_group which deletes these sysfs entries is<br /> called after releasing their metadata file inodes.<br /> <br /> Therefore, access to some of these sysfs attributes may occur outside of<br /> the lifetime of these metadata files, resulting in inode NULL pointer<br /> dereferences or use-after-free.<br /> <br /> In addition, the call to nilfs_sysfs_create_device_group() is made during<br /> the locking period of the semaphore "ns_sem" of nilfs object, so the<br /> shrinker call caused by the memory allocation for the sysfs entries, may<br /> derive lock dependencies "ns_sem" -&gt; (shrinker) -&gt; "locks acquired in<br /> nilfs_evict_inode()".<br /> <br /> Since nilfs2 may acquire "ns_sem" deep in the call stack holding other<br /> locks via its error handler __nilfs_error(), this causes lockdep to report<br /> circular locking. This is a false positive and no circular locking<br /> actually occurs as no inodes exist yet when<br /> nilfs_sysfs_create_device_group() is called. Fortunately, the lockdep<br /> warnings can be resolved by simply moving the call to<br /> nilfs_sysfs_create_device_group() out of "ns_sem".<br /> <br /> This fixes these sysfs issues by revising where the device&amp;#39;s sysfs<br /> interface is created/deleted and keeping its lifetime within the lifetime<br /> of the metadata files above.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: cpumap: Fix memory leak in cpu_map_update_elem<br /> <br /> Syzkaller reported a memory leak as follows:<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff110001198ef748 (size 192):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J...........<br /> 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(.......<br /> backtrace:<br /> [] __cpu_map_entry_alloc+0xf7/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff110001198ef528 (size 192):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __cpu_map_entry_alloc+0x260/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> BUG: memory leak<br /> unreferenced object 0xff1100010fd93d68 (size 8):<br /> comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s)<br /> hex dump (first 8 bytes):<br /> 00 00 00 00 00 00 00 00 ........<br /> backtrace:<br /> [] kvmalloc_node+0x11e/0x170<br /> [] __cpu_map_entry_alloc+0x2f0/0xb00<br /> [] cpu_map_update_elem+0x2fe/0x3d0<br /> [] bpf_map_update_value.isra.0+0x2bd/0x520<br /> [] map_update_elem+0x4cb/0x720<br /> [] __se_sys_bpf+0x8c3/0xb90<br /> [] do_syscall_64+0x30/0x40<br /> [] entry_SYSCALL_64_after_hwframe+0x61/0xc6<br /> <br /> In the cpu_map_update_elem flow, when kthread_stop is called before<br /> calling the threadfn of rcpu-&gt;kthread, since the KTHREAD_SHOULD_STOP bit<br /> of kthread has been set by kthread_stop, the threadfn of rcpu-&gt;kthread<br /> will never be executed, and rcpu-&gt;refcnt will never be 0, which will<br /> lead to the allocated rcpu, rcpu-&gt;queue and rcpu-&gt;queue-&gt;queue cannot be<br /> released.<br /> <br /> Calling kthread_stop before executing kthread&amp;#39;s threadfn will return<br /> -EINTR. We can complete the release of memory resources in this state.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Block switchdev mode when ADQ is active and vice versa<br /> <br /> ADQ and switchdev are not supported simultaneously. Enabling both at the<br /> same time can result in nullptr dereference.<br /> <br /> To prevent this, check if ADQ is active when changing devlink mode to<br /> switchdev mode, and check if switchdev is active when enabling ADQ.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak<br /> <br /> In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get()<br /> as pm_runtime_get_sync() will increase the refcnt even when it<br /> returns an error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: fix bulk_move corruption when adding a entry<br /> <br /> When the resource is the first in the bulk_move range, adding it again<br /> (thus moving it to the tail) will corrupt the list since the first<br /> pointer is not moved. This eventually lead to null pointer deref in<br /> ttm_lru_bulk_move_del()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: Fix a refcount bug in qrtr_recvmsg()<br /> <br /> Syzbot reported a bug as following:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> ...<br /> RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25<br /> ...<br /> Call Trace:<br /> <br /> __refcount_add include/linux/refcount.h:199 [inline]<br /> __refcount_inc include/linux/refcount.h:250 [inline]<br /> refcount_inc include/linux/refcount.h:267 [inline]<br /> kref_get include/linux/kref.h:45 [inline]<br /> qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline]<br /> qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline]<br /> qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline]<br /> qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070<br /> sock_recvmsg_nosec net/socket.c:1017 [inline]<br /> sock_recvmsg+0xe2/0x160 net/socket.c:1038<br /> qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688<br /> process_one_work+0x991/0x15c0 kernel/workqueue.c:2390<br /> worker_thread+0x669/0x1090 kernel/workqueue.c:2537<br /> <br /> It occurs in the concurrent scenario of qrtr_recvmsg() and<br /> qrtr_endpoint_unregister() as following:<br /> <br /> cpu0 cpu1<br /> qrtr_recvmsg qrtr_endpoint_unregister<br /> qrtr_send_resume_tx qrtr_node_release<br /> qrtr_node_lookup mutex_lock(&amp;qrtr_node_lock)<br /> spin_lock_irqsave(&amp;qrtr_nodes_lock, ) refcount_dec_and_test(&amp;node-&gt;ref) [node-&gt;ref == 0]<br /> radix_tree_lookup [node != NULL] __qrtr_node_release<br /> qrtr_node_acquire spin_lock_irqsave(&amp;qrtr_nodes_lock, )<br /> kref_get(&amp;node-&gt;ref) [WARNING] ...<br /> mutex_unlock(&amp;qrtr_node_lock)<br /> <br /> Use qrtr_node_lock to protect qrtr_node_lookup() implementation, this<br /> is actually improving the protection of node reference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free<br /> <br /> Struct pcie_link_state-&gt;downstream is a pointer to the pci_dev of function<br /> 0. Previously we retained that pointer when removing function 0, and<br /> subsequent ASPM policy changes dereferenced it, resulting in a<br /> use-after-free warning from KASAN, e.g.:<br /> <br /> # echo 1 &gt; /sys/bus/pci/devices/0000:03:00.0/remove<br /> # echo powersave &gt; /sys/module/pcie_aspm/parameters/policy<br /> <br /> BUG: KASAN: slab-use-after-free in pcie_config_aspm_link+0x42d/0x500<br /> Call Trace:<br /> kasan_report+0xae/0xe0<br /> pcie_config_aspm_link+0x42d/0x500<br /> pcie_aspm_set_policy+0x8e/0x1a0<br /> param_attr_store+0x162/0x2c0<br /> module_attr_store+0x3e/0x80<br /> <br /> PCIe spec r6.0, sec 7.5.3.7, recommends that software program the same ASPM<br /> Control value in all functions of multi-function devices.<br /> <br /> Disable ASPM and free the pcie_link_state when any child function is<br /> removed so we can discard the dangling pcie_link_state-&gt;downstream pointer<br /> and maintain the same ASPM Control configuration for all functions.<br /> <br /> [bhelgaas: commit log and comment]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Handle enclosure with just a primary component gracefully<br /> <br /> This reverts commit 3fe97ff3d949 ("scsi: ses: Don&amp;#39;t attach if enclosure<br /> has no components") and introduces proper handling of case where there are<br /> no detected secondary components, but primary component (enumerated in<br /> num_enclosures) does exist. That fix was originally proposed by Ding Hui<br /> .<br /> <br /> Completely ignoring devices that have one primary enclosure and no<br /> secondary one results in ses_intf_add() bailing completely<br /> <br /> scsi 2:0:0:254: enclosure has no enumerated components<br /> scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such<br /> <br /> even on valid configurations with 1 primary and 0 secondary enclosures as<br /> below:<br /> <br /> # sg_ses /dev/sg0<br /> 3PARdata SES 3321<br /> Supported diagnostic pages:<br /> Supported Diagnostic Pages [sdp] [0x0]<br /> Configuration (SES) [cf] [0x1]<br /> Short Enclosure Status (SES) [ses] [0x8]<br /> # sg_ses -p cf /dev/sg0<br /> 3PARdata SES 3321<br /> Configuration diagnostic page:<br /> number of secondary subenclosures: 0<br /> generation code: 0x0<br /> enclosure descriptor list<br /> Subenclosure identifier: 0 [primary]<br /> relative ES process id: 0, number of ES processes: 1<br /> number of type descriptor headers: 1<br /> enclosure logical identifier (hex): 20000002ac02068d<br /> enclosure vendor: 3PARdata product: VV rev: 3321<br /> type descriptor header and text list<br /> Element type: Unspecified, subenclosure id: 0<br /> number of possible elements: 1<br /> <br /> The changelog for the original fix follows<br /> <br /> =====<br /> We can get a crash when disconnecting the iSCSI session,<br /> the call trace like this:<br /> <br /> [ffff00002a00fb70] kfree at ffff00000830e224<br /> [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4<br /> [ffff00002a00fbd0] device_del at ffff0000086b6a98<br /> [ffff00002a00fc50] device_unregister at ffff0000086b6d58<br /> [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c<br /> [ffff00002a00fca0] scsi_remove_device at ffff000008706134<br /> [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4<br /> [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0<br /> [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4<br /> [ffff00002a00fdb0] process_one_work at ffff00000810f35c<br /> [ffff00002a00fe00] worker_thread at ffff00000810f648<br /> [ffff00002a00fe70] kthread at ffff000008116e98<br /> <br /> In ses_intf_add, components count could be 0, and kcalloc 0 size scomp,<br /> but not saved in edev-&gt;component[i].scratch<br /> <br /> In this situation, edev-&gt;component[0].scratch is an invalid pointer,<br /> when kfree it in ses_intf_remove_enclosure, a crash like above would happen<br /> The call trace also could be other random cases when kfree cannot catch<br /> the invalid pointer<br /> <br /> We should not use edev-&gt;component[] array when the components count is 0<br /> We also need check index when use edev-&gt;component[] array in<br /> ses_enclosure_data_process<br /> =====

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firewire: net: fix use after free in fwnet_finish_incoming_packet()<br /> <br /> The netif_rx() function frees the skb so we can&amp;#39;t dereference it to<br /> save the skb-&gt;len.