Vulnerabilities

An issue was discovered in the methods push.lite.avtech.com.AvtechLib.GetHttpsResponse and push.lite.avtech.com.Push_HttpService.getNewHttpClient in AVTECH EagleEyes 2.0.0. The methods set ALLOW_ALL_HOSTNAME_VERIFIER, bypassing domain validation.

An issue was discovered in the method push.lite.avtech.com.AvtechLib.GetHttpsResponse in AVTECH EagleEyes Lite 2.0.0, the GetHttpsResponse method transmits sensitive information - including internal server URLs, account IDs, passwords, and device tokens - as plaintext query parameters over HTTPS

An issue was discovered in the method push.lite.avtech.com.MySSLSocketFactoryNew.checkServerTrusted in AVTECH EagleEyes 2.0.0. The custom X509TrustManager used in checkServerTrusted only checks the certificate's expiration date, skipping proper TLS chain validation.

A Cross-Site Request Forgery (CSRF) vulnerability was identified in the Profile Page of the PHPGurukul Student-Result-Management-System-Using-PHP-V2.0. This flaw allows an attacker to trick authenticated users into unintentionally modifying their account details. By crafting a malicious HTML page, an attacker can submit unauthorized requests to the vulnerable endpoint: /create-class.php.

A vulnerability was detected in Campcodes Online Job Finder System 1.0. The impacted element is an unknown function of the file /eris/applicationform.php. The manipulation of the argument picture results in unrestricted upload. It is possible to launch the attack remotely. The exploit is now public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> USB: uhci: fix memory leak with using debugfs_lookup()<br /> <br /> When calling debugfs_lookup() the result must have dput() called on it,<br /> otherwise the memory will leak over time. To make things simpler, just<br /> call debugfs_lookup_and_remove() instead which handles all of the logic<br /> at once.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> raw: Fix NULL deref in raw_get_next().<br /> <br /> Dae R. Jeong reported a NULL deref in raw_get_next() [0].<br /> <br /> It seems that the repro was running these sequences in parallel so<br /> that one thread was iterating on a socket that was being freed in<br /> another netns.<br /> <br /> unshare(0x40060200)<br /> r0 = syz_open_procfs(0x0, &amp;(0x7f0000002080)=&amp;#39;net/raw\x00&amp;#39;)<br /> socket$inet_icmp_raw(0x2, 0x3, 0x1)<br /> pread64(r0, &amp;(0x7f0000000000)=""/10, 0xa, 0x10000000007f)<br /> <br /> After commit 0daf07e52709 ("raw: convert raw sockets to RCU"), we<br /> use RCU and hlist_nulls_for_each_entry() to iterate over SOCK_RAW<br /> sockets. However, we should use spinlock for slow paths to avoid<br /> the NULL deref.<br /> <br /> Also, SOCK_RAW does not use SLAB_TYPESAFE_BY_RCU, and the slab object<br /> is not reused during iteration in the grace period. In fact, the<br /> lockless readers do not check the nulls marker with get_nulls_value().<br /> So, SOCK_RAW should use hlist instead of hlist_nulls.<br /> <br /> Instead of adding an unnecessary barrier by sk_nulls_for_each_rcu(),<br /> let&amp;#39;s convert hlist_nulls to hlist and use sk_for_each_rcu() for<br /> fast paths and sk_for_each() and spinlock for /proc/net/raw.<br /> <br /> [0]:<br /> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> CPU: 2 PID: 20952 Comm: syz-executor.0 Not tainted 6.2.0-g048ec869bafd-dirty #7<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:read_pnet include/net/net_namespace.h:383 [inline]<br /> RIP: 0010:sock_net include/net/sock.h:649 [inline]<br /> RIP: 0010:raw_get_next net/ipv4/raw.c:974 [inline]<br /> RIP: 0010:raw_get_idx net/ipv4/raw.c:986 [inline]<br /> RIP: 0010:raw_seq_start+0x431/0x800 net/ipv4/raw.c:995<br /> Code: ef e8 33 3d 94 f7 49 8b 6d 00 4c 89 ef e8 b7 65 5f f7 49 89 ed 49 83 c5 98 0f 84 9a 00 00 00 48 83 c5 c8 48 89 e8 48 c1 e8 03 80 3c 30 00 74 08 48 89 ef e8 00 3d 94 f7 4c 8b 7d 00 48 89 ef<br /> RSP: 0018:ffffc9001154f9b0 EFLAGS: 00010206<br /> RAX: 0000000000000005 RBX: 1ffff1100302c8fd RCX: 0000000000000000<br /> RDX: 0000000000000028 RSI: ffffc9001154f988 RDI: ffffc9000f77a338<br /> RBP: 0000000000000029 R08: ffffffff8a50ffb4 R09: fffffbfff24b6bd9<br /> R10: fffffbfff24b6bd9 R11: 0000000000000000 R12: ffff88801db73b78<br /> R13: fffffffffffffff9 R14: dffffc0000000000 R15: 0000000000000030<br /> FS: 00007f843ae8e700(0000) GS:ffff888063700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055bb9614b35f CR3: 000000003c672000 CR4: 00000000003506e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> seq_read_iter+0x4c6/0x10f0 fs/seq_file.c:225<br /> seq_read+0x224/0x320 fs/seq_file.c:162<br /> pde_read fs/proc/inode.c:316 [inline]<br /> proc_reg_read+0x23f/0x330 fs/proc/inode.c:328<br /> vfs_read+0x31e/0xd30 fs/read_write.c:468<br /> ksys_pread64 fs/read_write.c:665 [inline]<br /> __do_sys_pread64 fs/read_write.c:675 [inline]<br /> __se_sys_pread64 fs/read_write.c:672 [inline]<br /> __x64_sys_pread64+0x1e9/0x280 fs/read_write.c:672<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x4e/0xa0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x478d29<br /> Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 bc ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007f843ae8dbe8 EFLAGS: 00000246 ORIG_RAX: 0000000000000011<br /> RAX: ffffffffffffffda RBX: 0000000000791408 RCX: 0000000000478d29<br /> RDX: 000000000000000a RSI: 0000000020000000 RDI: 0000000000000003<br /> RBP: 00000000f477909a R08: 0000000000000000 R09: 0000000000000000<br /> R10: 000010000000007f R11: 0000000000000246 R12: 0000000000791740<br /> R13: 0000000000791414 R14: 0000000000791408 R15: 00007ffc2eb48a50<br /> <br /> Modules linked in:<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mlxsw: minimal: fix potential memory leak in mlxsw_m_linecards_init<br /> <br /> The line cards array is not freed in the error path of<br /> mlxsw_m_linecards_init(), which can lead to a memory leak. Fix by<br /> freeing the array in the error path, thereby making the error path<br /> identical to mlxsw_m_linecards_fini().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/ntfs3: Add length check in indx_get_root<br /> <br /> This adds a length check to guarantee the retrieved index root is legit.<br /> <br /> [ 162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243<br /> [ 162.460851]<br /> [ 162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42<br /> [ 162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 162.462609] Call Trace:<br /> [ 162.462954] <br /> [ 162.463276] dump_stack_lvl+0x49/0x63<br /> [ 162.463822] print_report.cold+0xf5/0x689<br /> [ 162.464608] ? unwind_get_return_address+0x3a/0x60<br /> [ 162.465766] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.466975] kasan_report+0xa7/0x130<br /> [ 162.467506] ? _raw_spin_lock_irq+0xc0/0xf0<br /> [ 162.467998] ? hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.468536] __asan_load2+0x68/0x90<br /> [ 162.468923] hdr_find_e.isra.0+0x10c/0x320<br /> [ 162.469282] ? cmp_uints+0xe0/0xe0<br /> [ 162.469557] ? cmp_sdh+0x90/0x90<br /> [ 162.469864] ? ni_find_attr+0x214/0x300<br /> [ 162.470217] ? ni_load_mi+0x80/0x80<br /> [ 162.470479] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.470931] ? ntfs_bread_run+0x190/0x190<br /> [ 162.471307] ? indx_get_root+0xe4/0x190<br /> [ 162.471556] ? indx_get_root+0x140/0x190<br /> [ 162.471833] ? indx_init+0x1e0/0x1e0<br /> [ 162.472069] ? fnd_clear+0x115/0x140<br /> [ 162.472363] ? _raw_spin_lock_irqsave+0x100/0x100<br /> [ 162.472731] indx_find+0x184/0x470<br /> [ 162.473461] ? sysvec_apic_timer_interrupt+0x57/0xc0<br /> [ 162.474429] ? indx_find_buffer+0x2d0/0x2d0<br /> [ 162.474704] ? do_syscall_64+0x3b/0x90<br /> [ 162.474962] dir_search_u+0x196/0x2f0<br /> [ 162.475381] ? ntfs_nls_to_utf16+0x450/0x450<br /> [ 162.475661] ? ntfs_security_init+0x3d6/0x440<br /> [ 162.475906] ? is_sd_valid+0x180/0x180<br /> [ 162.476191] ntfs_extend_init+0x13f/0x2c0<br /> [ 162.476496] ? ntfs_fix_post_read+0x130/0x130<br /> [ 162.476861] ? iput.part.0+0x286/0x320<br /> [ 162.477325] ntfs_fill_super+0x11e0/0x1b50<br /> [ 162.477709] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.477970] ? vsprintf+0x20/0x20<br /> [ 162.478258] ? set_blocksize+0x95/0x150<br /> [ 162.478538] get_tree_bdev+0x232/0x370<br /> [ 162.478789] ? put_ntfs+0x1d0/0x1d0<br /> [ 162.479038] ntfs_fs_get_tree+0x15/0x20<br /> [ 162.479374] vfs_get_tree+0x4c/0x130<br /> [ 162.479729] path_mount+0x654/0xfe0<br /> [ 162.480124] ? putname+0x80/0xa0<br /> [ 162.480484] ? finish_automount+0x2e0/0x2e0<br /> [ 162.480894] ? putname+0x80/0xa0<br /> [ 162.481467] ? kmem_cache_free+0x1c4/0x440<br /> [ 162.482280] ? putname+0x80/0xa0<br /> [ 162.482714] do_mount+0xd6/0xf0<br /> [ 162.483264] ? path_mount+0xfe0/0xfe0<br /> [ 162.484782] ? __kasan_check_write+0x14/0x20<br /> [ 162.485593] __x64_sys_mount+0xca/0x110<br /> [ 162.486024] do_syscall_64+0x3b/0x90<br /> [ 162.486543] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 162.487141] RIP: 0033:0x7f9d374e948a<br /> [ 162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008<br /> [ 162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5<br /> [ 162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a<br /> [ 162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0<br /> [ 162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020<br /> [ 162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0<br /> [ 162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff<br /> [ 162.493644] <br /> [ 162.493908]<br /> [ 162.494214] The buggy address belongs to the physical page:<br /> [ 162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc<br /> [ 162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)<br /> [ 162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000<br /> [ 162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000<br /> [ 162.500542] page dumped becau<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix amdgpu_irq_put call trace in gmc_v10_0_hw_fini<br /> <br /> The gmc.ecc_irq is enabled by firmware per IFWI setting,<br /> and the host driver is not privileged to enable/disable<br /> the interrupt. So, it is meaningless to use the amdgpu_irq_put<br /> function in gmc_v10_0_hw_fini, which also leads to the call<br /> trace.<br /> <br /> [ 82.340264] Call Trace:<br /> [ 82.340265] <br /> [ 82.340269] gmc_v10_0_hw_fini+0x83/0xa0 [amdgpu]<br /> [ 82.340447] gmc_v10_0_suspend+0xe/0x20 [amdgpu]<br /> [ 82.340623] amdgpu_device_ip_suspend_phase2+0x127/0x1c0 [amdgpu]<br /> [ 82.340789] amdgpu_device_ip_suspend+0x3d/0x80 [amdgpu]<br /> [ 82.340955] amdgpu_device_pre_asic_reset+0xdd/0x2b0 [amdgpu]<br /> [ 82.341122] amdgpu_device_gpu_recover.cold+0x4dd/0xbb2 [amdgpu]<br /> [ 82.341359] amdgpu_debugfs_reset_work+0x4c/0x70 [amdgpu]<br /> [ 82.341529] process_one_work+0x21d/0x3f0<br /> [ 82.341535] worker_thread+0x1fa/0x3c0<br /> [ 82.341538] ? process_one_work+0x3f0/0x3f0<br /> [ 82.341540] kthread+0xff/0x130<br /> [ 82.341544] ? kthread_complete_and_exit+0x20/0x20<br /> [ 82.341547] ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix nexthop hash size<br /> <br /> The nexthop code expects a 31 bit hash, such as what is returned by<br /> fib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hash<br /> returned by skb_get_hash() can lead to problems related to the fact that<br /> &amp;#39;int hash&amp;#39; is a negative number when the MSB is set.<br /> <br /> In the case of hash threshold nexthop groups, nexthop_select_path_hthr()<br /> will disproportionately select the first nexthop group entry. In the case<br /> of resilient nexthop groups, nexthop_select_path_res() may do an out of<br /> bounds access in nh_buckets[], for example:<br /> hash = -912054133<br /> num_nh_buckets = 2<br /> bucket_index = 65535<br /> <br /> which leads to the following panic:<br /> <br /> BUG: unable to handle page fault for address: ffffc900025910c8<br /> PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0<br /> Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI<br /> CPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> Workqueue: ipv6_addrconf addrconf_dad_work<br /> RIP: 0010:nexthop_select_path+0x197/0xbf0<br /> Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85<br /> RSP: 0018:ffff88810c36f260 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8<br /> RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219<br /> R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0<br /> R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900<br /> FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x1ee/0x5c0<br /> ? __pfx_is_prefetch.constprop.0+0x10/0x10<br /> ? __pfx_page_fault_oops+0x10/0x10<br /> ? search_bpf_extables+0xfe/0x1c0<br /> ? fixup_exception+0x3b/0x470<br /> ? exc_page_fault+0xf6/0x110<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? nexthop_select_path+0x197/0xbf0<br /> ? lock_is_held_type+0xe7/0x140<br /> vxlan_xmit+0x5b2/0x2340<br /> ? __lock_acquire+0x92b/0x3370<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_register_lock_class+0x10/0x10<br /> ? skb_network_protocol+0xce/0x2d0<br /> ? dev_hard_start_xmit+0xca/0x350<br /> ? __pfx_vxlan_xmit+0x10/0x10<br /> dev_hard_start_xmit+0xca/0x350<br /> __dev_queue_xmit+0x513/0x1e20<br /> ? __pfx___dev_queue_xmit+0x10/0x10<br /> ? __pfx_lock_release+0x10/0x10<br /> ? mark_held_locks+0x44/0x90<br /> ? skb_push+0x4c/0x80<br /> ? eth_header+0x81/0xe0<br /> ? __pfx_eth_header+0x10/0x10<br /> ? neigh_resolve_output+0x215/0x310<br /> ? ip6_finish_output2+0x2ba/0xc90<br /> ip6_finish_output2+0x2ba/0xc90<br /> ? lock_release+0x236/0x3e0<br /> ? ip6_mtu+0xbb/0x240<br /> ? __pfx_ip6_finish_output2+0x10/0x10<br /> ? find_held_lock+0x83/0xa0<br /> ? lock_is_held_type+0xe7/0x140<br /> ip6_finish_output+0x1ee/0x780<br /> ip6_output+0x138/0x460<br /> ? __pfx_ip6_output+0x10/0x10<br /> ? __pfx___lock_acquire+0x10/0x10<br /> ? __pfx_ip6_finish_output+0x10/0x10<br /> NF_HOOK.constprop.0+0xc0/0x420<br /> ? __pfx_NF_HOOK.constprop.0+0x10/0x10<br /> ? ndisc_send_skb+0x2c0/0x960<br /> ? __pfx_lock_release+0x10/0x10<br /> ? __local_bh_enable_ip+0x93/0x110<br /> ? lock_is_held_type+0xe7/0x140<br /> ndisc_send_skb+0x4be/0x960<br /> ? __pfx_ndisc_send_skb+0x10/0x10<br /> ? mark_held_locks+0x65/0x90<br /> ? find_held_lock+0x83/0xa0<br /> ndisc_send_ns+0xb0/0x110<br /> ? __pfx_ndisc_send_ns+0x10/0x10<br /> addrconf_dad_work+0x631/0x8e0<br /> ? lock_acquire+0x180/0x3f0<br /> ? __pfx_addrconf_dad_work+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> process_one_work+0x582/0x9c0<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? __pfx_do_raw_spin_lock+0x10/0x10<br /> ? mark_held_locks+0x24/0x90<br /> worker_thread+0x93/0x630<br /> ? __kthread_parkme+0xdc/0x100<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1a5/0x1e0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x60<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domains<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.