Vulnerabilities

Cross Site Request Forgery (CSRF) vulnerability in Smartvista BackOffice SmartVista Suite 2.2.22 via crafted GET request.

A vulnerability was identified in fuyang_lipengjun platform 1.0. This affects the function AttributeCategoryController of the file /attributecategory/queryAll. Such manipulation leads to improper authorization. The attack may be launched remotely. The exploit is publicly available and might be used.

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.

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)

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

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.

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.

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.

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.

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()

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.

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]