Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/vmci: Clear the vmci transport packet properly when initializing it<br /> <br /> In vmci_transport_packet_init memset the vmci_transport_packet before<br /> populating the fields to avoid any uninitialised data being left in the<br /> structure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: displayport: Fix potential deadlock<br /> <br /> The deadlock can occur due to a recursive lock acquisition of<br /> `cros_typec_altmode_data::mutex`.<br /> The call chain is as follows:<br /> 1. cros_typec_altmode_work() acquires the mutex<br /> 2. typec_altmode_vdm() -&gt; dp_altmode_vdm() -&gt;<br /> 3. typec_altmode_exit() -&gt; cros_typec_altmode_exit()<br /> 4. cros_typec_altmode_exit() attempts to acquire the mutex again<br /> <br /> To prevent this, defer the `typec_altmode_exit()` call by scheduling<br /> it rather than calling it directly from within the mutex-protected<br /> context.

A reflected cross-site scripting (XSS) vulnerability exists in Institute-of-Current-Students v1.0 via the email parameter in the /postquerypublic endpoint. The application fails to properly sanitize user input before reflecting it in the HTML response. This allows unauthenticated attackers to inject and execute arbitrary JavaScript code in the context of the victim&amp;#39;s browser by tricking them into visiting a crafted URL or submitting a malicious form. Successful exploitation may lead to session hijacking, credential theft, or other client-side attacks.

A vulnerability was found in PHPGurukul User Registration &amp; Login and User Management 3.3 and classified as critical. Affected by this issue is some unknown functionality of the file /admin/lastsevendays-reg-users.php. The manipulation of the argument ID leads to sql injection. The attack may be launched remotely. The exploit has been disclosed to the public and may be used.

A vulnerability was found in PHPGurukul User Registration &amp; Login and User Management 3.3. It has been classified as critical. This affects an unknown part of the file /admin/lastthirtyays-reg-users.php. The manipulation of the argument ID leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs: export anon_inode_make_secure_inode() and fix secretmem LSM bypass<br /> <br /> Export anon_inode_make_secure_inode() to allow KVM guest_memfd to create<br /> anonymous inodes with proper security context. This replaces the current<br /> pattern of calling alloc_anon_inode() followed by<br /> inode_init_security_anon() for creating security context manually.<br /> <br /> This change also fixes a security regression in secretmem where the<br /> S_PRIVATE flag was not cleared after alloc_anon_inode(), causing<br /> LSM/SELinux checks to be bypassed for secretmem file descriptors.<br /> <br /> As guest_memfd currently resides in the KVM module, we need to export this<br /> symbol for use outside the core kernel. In the future, guest_memfd might be<br /> moved to core-mm, at which point the symbols no longer would have to be<br /> exported. When/if that happens is still unclear.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()<br /> <br /> The function core_scsi3_decode_spec_i_port(), in its error code path,<br /> unconditionally calls core_scsi3_lunacl_undepend_item() passing the<br /> dest_se_deve pointer, which may be NULL.<br /> <br /> This can lead to a NULL pointer dereference if dest_se_deve remains<br /> unset.<br /> <br /> SPC-3 PR SPEC_I_PT: Unable to locate dest_tpg<br /> Unable to handle kernel paging request at virtual address dfff800000000012<br /> Call trace:<br /> core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P)<br /> core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod]<br /> core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod]<br /> target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]<br /> <br /> Fix this by adding a NULL check before calling<br /> core_scsi3_lunacl_undepend_item()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtk-sd: Prevent memory corruption from DMA map failure<br /> <br /> If msdc_prepare_data() fails to map the DMA region, the request is<br /> not prepared for data receiving, but msdc_start_data() proceeds<br /> the DMA with previous setting.<br /> Since this will lead a memory corruption, we have to stop the<br /> request operation soon after the msdc_prepare_data() fails to<br /> prepare it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-qpic-snand: reallocate BAM transactions<br /> <br /> Using the mtd_nandbiterrs module for testing the driver occasionally<br /> results in weird things like below.<br /> <br /> 1. swiotlb mapping fails with the following message:<br /> <br /> [ 85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)<br /> [ 85.932937] qcom_snand 79b0000.spi: failure in mapping desc<br /> [ 87.999314] qcom_snand 79b0000.spi: failure to write raw page<br /> [ 87.999352] mtd_nandbiterrs: error: write_oob failed (-110)<br /> <br /> Rebooting the board after this causes a panic due to a NULL pointer<br /> dereference.<br /> <br /> 2. If the swiotlb mapping does not fail, rebooting the board may result<br /> in a different panic due to a bad spinlock magic:<br /> <br /> [ 256.104459] BUG: spinlock bad magic on CPU#3, procd/2241<br /> [ 256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b<br /> ...<br /> <br /> Investigating the issue revealed that these symptoms are results of<br /> memory corruption which is caused by out of bounds access within the<br /> driver.<br /> <br /> The driver uses a dynamically allocated structure for BAM transactions,<br /> which structure must have enough space for all possible variations of<br /> different flash operations initiated by the driver. The required space<br /> heavily depends on the actual number of &amp;#39;codewords&amp;#39; which is calculated<br /> from the pagesize of the actual NAND chip.<br /> <br /> Although the qcom_nandc_alloc() function allocates memory for the BAM<br /> transactions during probe, but since the actual number of &amp;#39;codewords&amp;#39;<br /> is not yet know the allocation is done for one &amp;#39;codeword&amp;#39; only.<br /> <br /> Because of this, whenever the driver does a flash operation, and the<br /> number of the required transactions exceeds the size of the allocated<br /> arrays the driver accesses memory out of the allocated range.<br /> <br /> To avoid this, change the code to free the initially allocated BAM<br /> transactions memory, and allocate a new one once the actual number of<br /> &amp;#39;codewords&amp;#39; required for a given NAND chip is known.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: return 0 size for RSS key if not supported<br /> <br /> Returning -EOPNOTSUPP from function returning u32 is leading to<br /> cast and invalid size value as a result.<br /> <br /> -EOPNOTSUPP as a size probably will lead to allocation fail.<br /> <br /> Command: ethtool -x eth0<br /> It is visible on all devices that don&amp;#39;t have RSS caps set.<br /> <br /> [ 136.615917] Call Trace:<br /> [ 136.615921] <br /> [ 136.615927] ? __warn+0x89/0x130<br /> [ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330<br /> [ 136.615953] ? report_bug+0x164/0x190<br /> [ 136.615968] ? handle_bug+0x58/0x90<br /> [ 136.615979] ? exc_invalid_op+0x17/0x70<br /> [ 136.615987] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330<br /> [ 136.616028] __alloc_pages_noprof+0xe/0x20<br /> [ 136.616038] ___kmalloc_large_node+0x80/0x110<br /> [ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0<br /> [ 136.616081] __kmalloc_noprof+0x32c/0x4c0<br /> [ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170<br /> [ 136.616114] ethnl_default_doit+0x107/0x3d0<br /> [ 136.616131] genl_family_rcv_msg_doit+0x100/0x160<br /> [ 136.616147] genl_rcv_msg+0x1b8/0x2c0<br /> [ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10<br /> [ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [ 136.616176] netlink_rcv_skb+0x58/0x110<br /> [ 136.616186] genl_rcv+0x28/0x40<br /> [ 136.616195] netlink_unicast+0x19b/0x290<br /> [ 136.616206] netlink_sendmsg+0x222/0x490<br /> [ 136.616215] __sys_sendto+0x1fd/0x210<br /> [ 136.616233] __x64_sys_sendto+0x24/0x30<br /> [ 136.616242] do_syscall_64+0x82/0x160<br /> [ 136.616252] ? __sys_recvmsg+0x83/0xe0<br /> [ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210<br /> [ 136.616275] ? do_syscall_64+0x8e/0x160<br /> [ 136.616282] ? __count_memcg_events+0xa1/0x130<br /> [ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30<br /> [ 136.616306] ? handle_mm_fault+0xae/0x2d0<br /> [ 136.616319] ? do_user_addr_fault+0x379/0x670<br /> [ 136.616328] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616340] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616349] ? clear_bhb_loop+0x45/0xa0<br /> [ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 136.616369] RIP: 0033:0x7fd30ba7b047<br /> [ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44<br /> [ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c<br /> [ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047<br /> [ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003<br /> [ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c<br /> [ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340<br /> [ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-multipath: fix suspicious RCU usage warning<br /> <br /> When I run the NVME over TCP test in virtme-ng, I get the following<br /> "suspicious RCU usage" warning in nvme_mpath_add_sysfs_link():<br /> <br /> &amp;#39;&amp;#39;&amp;#39;<br /> [ 5.024557][ T44] nvmet: Created nvm controller 1 for subsystem nqn.2025-06.org.nvmexpress.mptcp for NQN nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77.<br /> [ 5.027401][ T183] nvme nvme0: creating 2 I/O queues.<br /> [ 5.029017][ T183] nvme nvme0: mapped 2/0/0 default/read/poll queues.<br /> [ 5.032587][ T183] nvme nvme0: new ctrl: NQN "nqn.2025-06.org.nvmexpress.mptcp", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:f7f6b5e0-ff97-4894-98ac-c85309e0bc77<br /> [ 5.042214][ T25]<br /> [ 5.042440][ T25] =============================<br /> [ 5.042579][ T25] WARNING: suspicious RCU usage<br /> [ 5.042705][ T25] 6.16.0-rc3+ #23 Not tainted<br /> [ 5.042812][ T25] -----------------------------<br /> [ 5.042934][ T25] drivers/nvme/host/multipath.c:1203 RCU-list traversed in non-reader section!!<br /> [ 5.043111][ T25]<br /> [ 5.043111][ T25] other info that might help us debug this:<br /> [ 5.043111][ T25]<br /> [ 5.043341][ T25]<br /> [ 5.043341][ T25] rcu_scheduler_active = 2, debug_locks = 1<br /> [ 5.043502][ T25] 3 locks held by kworker/u9:0/25:<br /> [ 5.043615][ T25] #0: ffff888008730948 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x7ed/0x1350<br /> [ 5.043830][ T25] #1: ffffc900001afd40 ((work_completion)(&amp;entry-&gt;work)){+.+.}-{0:0}, at: process_one_work+0xcf3/0x1350<br /> [ 5.044084][ T25] #2: ffff888013ee0020 (&amp;head-&gt;srcu){.+.+}-{0:0}, at: nvme_mpath_add_sysfs_link.part.0+0xb4/0x3a0<br /> [ 5.044300][ T25]<br /> [ 5.044300][ T25] stack backtrace:<br /> [ 5.044439][ T25] CPU: 0 UID: 0 PID: 25 Comm: kworker/u9:0 Not tainted 6.16.0-rc3+ #23 PREEMPT(full)<br /> [ 5.044441][ T25] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011<br /> [ 5.044442][ T25] Workqueue: async async_run_entry_fn<br /> [ 5.044445][ T25] Call Trace:<br /> [ 5.044446][ T25] <br /> [ 5.044449][ T25] dump_stack_lvl+0x6f/0xb0<br /> [ 5.044453][ T25] lockdep_rcu_suspicious.cold+0x4f/0xb1<br /> [ 5.044457][ T25] nvme_mpath_add_sysfs_link.part.0+0x2fb/0x3a0<br /> [ 5.044459][ T25] ? queue_work_on+0x90/0xf0<br /> [ 5.044461][ T25] ? lockdep_hardirqs_on+0x78/0x110<br /> [ 5.044466][ T25] nvme_mpath_set_live+0x1e9/0x4f0<br /> [ 5.044470][ T25] nvme_mpath_add_disk+0x240/0x2f0<br /> [ 5.044472][ T25] ? __pfx_nvme_mpath_add_disk+0x10/0x10<br /> [ 5.044475][ T25] ? add_disk_fwnode+0x361/0x580<br /> [ 5.044480][ T25] nvme_alloc_ns+0x81c/0x17c0<br /> [ 5.044483][ T25] ? kasan_quarantine_put+0x104/0x240<br /> [ 5.044487][ T25] ? __pfx_nvme_alloc_ns+0x10/0x10<br /> [ 5.044495][ T25] ? __pfx_nvme_find_get_ns+0x10/0x10<br /> [ 5.044496][ T25] ? rcu_read_lock_any_held+0x45/0xa0<br /> [ 5.044498][ T25] ? validate_chain+0x232/0x4f0<br /> [ 5.044503][ T25] nvme_scan_ns+0x4c8/0x810<br /> [ 5.044506][ T25] ? __pfx_nvme_scan_ns+0x10/0x10<br /> [ 5.044508][ T25] ? find_held_lock+0x2b/0x80<br /> [ 5.044512][ T25] ? ktime_get+0x16d/0x220<br /> [ 5.044517][ T25] ? kvm_clock_get_cycles+0x18/0x30<br /> [ 5.044520][ T25] ? __pfx_nvme_scan_ns_async+0x10/0x10<br /> [ 5.044522][ T25] async_run_entry_fn+0x97/0x560<br /> [ 5.044523][ T25] ? rcu_is_watching+0x12/0xc0<br /> [ 5.044526][ T25] process_one_work+0xd3c/0x1350<br /> [ 5.044532][ T25] ? __pfx_process_one_work+0x10/0x10<br /> [ 5.044536][ T25] ? assign_work+0x16c/0x240<br /> [ 5.044539][ T25] worker_thread+0x4da/0xd50<br /> [ 5.044545][ T25] ? __pfx_worker_thread+0x10/0x10<br /> [ 5.044546][ T25] kthread+0x356/0x5c0<br /> [ 5.044548][ T25] ? __pfx_kthread+0x10/0x10<br /> [ 5.044549][ T25] ? ret_from_fork+0x1b/0x2e0<br /> [ 5.044552][ T25] ? __lock_release.isra.0+0x5d/0x180<br /> [ 5.044553][ T25] ? ret_from_fork+0x1b/0x2e0<br /> [ 5.044555][ T25] ? rcu_is_watching+0x12/0xc0<br /> [ 5.044557][ T25] ? __pfx_kthread+0x10/0x10<br /> [ 5.04<br /> ---truncated---

JHipster before v.8.9.0 allows privilege escalation via a modified authorities parameter. Upon registering in the JHipster portal and logging in as a standard user, the authorities parameter in the response from the api/account endpoint contains the value ROLE_USER. By manipulating the authorities parameter and changing its value to ROLE_ADMIN, the privilege is successfully escalated to an Admin level. This allowed the access to all admin-related functionalities in the application. NOTE: this is disputed by the Supplier because there is no privilege escalation in the context of the JHipster backend (the report only demonstrates that, after using JHipster to generate an application, one can make a non-functional admin screen visible in the front end of that application).