Vulnerabilities

NiceGUI is a Python-based UI framework. Versions 3.3.1 and below are subject to a XSS vulnerability through the ui.interactive_image component of NiceGUI. The component renders SVG content using Vue's v-html directive without any sanitization. This allows attackers to inject malicious HTML or JavaScript via the SVG tag whenever the image component is rendered or updated. This is particularly dangerous for dashboards or multi-user applications displaying user-generated content or annotations. This issue is fixed in version 3.4.0.

A vulnerability was found in code-projects Employee Profile Management System 1.0. Affected is an unknown function of the file edit_personnel.php. The manipulation of the argument per_id results in sql injection. The attack can be launched remotely. The exploit has been made public and could be used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: release crypto keyslot before reporting I/O complete<br /> <br /> Once all I/O using a blk_crypto_key has completed, filesystems can call<br /> blk_crypto_evict_key(). However, the block layer currently doesn&amp;#39;t call<br /> blk_crypto_put_keyslot() until the request is being freed, which happens<br /> after upper layers have been told (via bio_endio()) the I/O has<br /> completed. This causes a race condition where blk_crypto_evict_key()<br /> can see &amp;#39;slot_refs != 0&amp;#39; without there being an actual bug.<br /> <br /> This makes __blk_crypto_evict_key() hit the<br /> &amp;#39;WARN_ON_ONCE(atomic_read(&amp;slot-&gt;slot_refs) != 0)&amp;#39; and return without<br /> doing anything, eventually causing a use-after-free in<br /> blk_crypto_reprogram_all_keys(). (This is a very rare bug and has only<br /> been seen when per-file keys are being used with fscrypt.)<br /> <br /> There are two options to fix this: either release the keyslot before<br /> bio_endio() is called on the request&amp;#39;s last bio, or make<br /> __blk_crypto_evict_key() ignore slot_refs. Let&amp;#39;s go with the first<br /> solution, since it preserves the ability to report bugs (via<br /> WARN_ON_ONCE) where a key is evicted while still in-use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Cap MSIX used to online CPUs + 1<br /> <br /> The irdma driver can use a maximum number of msix vectors equal<br /> to num_online_cpus() + 1 and the kernel warning stack below is shown<br /> if that number is exceeded.<br /> <br /> The kernel throws a warning as the driver tries to update the affinity<br /> hint with a CPU mask greater than the max CPU IDs. Fix this by capping<br /> the MSIX vectors to num_online_cpus() + 1.<br /> <br /> WARNING: CPU: 7 PID: 23655 at include/linux/cpumask.h:106 irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma]<br /> RIP: 0010:irdma_cfg_ceq_vector+0x34c/0x3f0 [irdma]<br /> Call Trace:<br /> irdma_rt_init_hw+0xa62/0x1290 [irdma]<br /> ? irdma_alloc_local_mac_entry+0x1a0/0x1a0 [irdma]<br /> ? __is_kernel_percpu_address+0x63/0x310<br /> ? rcu_read_lock_held_common+0xe/0xb0<br /> ? irdma_lan_unregister_qset+0x280/0x280 [irdma]<br /> ? irdma_request_reset+0x80/0x80 [irdma]<br /> ? ice_get_qos_params+0x84/0x390 [ice]<br /> irdma_probe+0xa40/0xfc0 [irdma]<br /> ? rcu_read_lock_bh_held+0xd0/0xd0<br /> ? irdma_remove+0x140/0x140 [irdma]<br /> ? rcu_read_lock_sched_held+0x62/0xe0<br /> ? down_write+0x187/0x3d0<br /> ? auxiliary_match_id+0xf0/0x1a0<br /> ? irdma_remove+0x140/0x140 [irdma]<br /> auxiliary_bus_probe+0xa6/0x100<br /> __driver_probe_device+0x4a4/0xd50<br /> ? __device_attach_driver+0x2c0/0x2c0<br /> driver_probe_device+0x4a/0x110<br /> __driver_attach+0x1aa/0x350<br /> bus_for_each_dev+0x11d/0x1b0<br /> ? subsys_dev_iter_init+0xe0/0xe0<br /> bus_add_driver+0x3b1/0x610<br /> driver_register+0x18e/0x410<br /> ? 0xffffffffc0b88000<br /> irdma_init_module+0x50/0xaa [irdma]<br /> do_one_initcall+0x103/0x5f0<br /> ? perf_trace_initcall_level+0x420/0x420<br /> ? do_init_module+0x4e/0x700<br /> ? __kasan_kmalloc+0x7d/0xa0<br /> ? kmem_cache_alloc_trace+0x188/0x2b0<br /> ? kasan_unpoison+0x21/0x50<br /> do_init_module+0x1d1/0x700<br /> load_module+0x3867/0x5260<br /> ? layout_and_allocate+0x3990/0x3990<br /> ? rcu_read_lock_held_common+0xe/0xb0<br /> ? rcu_read_lock_sched_held+0x62/0xe0<br /> ? rcu_read_lock_bh_held+0xd0/0xd0<br /> ? __vmalloc_node_range+0x46b/0x890<br /> ? lock_release+0x5c8/0xba0<br /> ? alloc_vm_area+0x120/0x120<br /> ? selinux_kernel_module_from_file+0x2a5/0x300<br /> ? __inode_security_revalidate+0xf0/0xf0<br /> ? __do_sys_init_module+0x1db/0x260<br /> __do_sys_init_module+0x1db/0x260<br /> ? load_module+0x5260/0x5260<br /> ? do_syscall_64+0x22/0x450<br /> do_syscall_64+0xa5/0x450<br /> entry_SYSCALL_64_after_hwframe+0x66/0xdb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: fix decoder disable pm crash<br /> <br /> Can&amp;#39;t call pm_runtime_disable when the architecture support sub device for<br /> &amp;#39;dev-&gt;pm.dev&amp;#39; is NUll, or will get below crash log.<br /> <br /> [ 10.771551] pc : _raw_spin_lock_irq+0x4c/0xa0<br /> [ 10.771556] lr : __pm_runtime_disable+0x30/0x130<br /> [ 10.771558] sp : ffffffc01e4cb800<br /> [ 10.771559] x29: ffffffc01e4cb800 x28: ffffffdf082108a8<br /> [ 10.771563] x27: ffffffc01e4cbd70 x26: ffffff8605df55f0<br /> [ 10.771567] x25: 0000000000000002 x24: 0000000000000002<br /> [ 10.771570] x23: ffffff85c0dc9c00 x22: 0000000000000001<br /> [ 10.771573] x21: 0000000000000001 x20: 0000000000000000<br /> [ 10.771577] x19: 00000000000000f4 x18: ffffffdf2e9fbe18<br /> [ 10.771580] x17: 0000000000000000 x16: ffffffdf2df13c74<br /> [ 10.771583] x15: 00000000000002ea x14: 0000000000000058<br /> [ 10.771587] x13: ffffffdf2de1b62c x12: ffffffdf2e9e30e4<br /> [ 10.771590] x11: 0000000000000000 x10: 0000000000000001<br /> [ 10.771593] x9 : 0000000000000000 x8 : 00000000000000f4<br /> [ 10.771596] x7 : 6bff6264632c6264 x6 : 0000000000008000<br /> [ 10.771600] x5 : 0080000000000000 x4 : 0000000000000001<br /> [ 10.771603] x3 : 0000000000000008 x2 : 0000000000000001<br /> [ 10.771608] x1 : 0000000000000000 x0 : 00000000000000f4<br /> [ 10.771613] Call trace:<br /> [ 10.771617] _raw_spin_lock_irq+0x4c/0xa0<br /> [ 10.771620] __pm_runtime_disable+0x30/0x130<br /> [ 10.771657] mtk_vcodec_probe+0x69c/0x728 [mtk_vcodec_dec 800cc929d6631f79f9b273254c8db94d0d3500dc]<br /> [ 10.771662] platform_drv_probe+0x9c/0xbc<br /> [ 10.771665] really_probe+0x13c/0x3a0<br /> [ 10.771668] driver_probe_device+0x84/0xc0<br /> [ 10.771671] device_driver_attach+0x54/0x78

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix rbtree traversal bug in ext4_mb_use_preallocated<br /> <br /> During allocations, while looking for preallocations(PA) in the per<br /> inode rbtree, we can&amp;#39;t do a direct traversal of the tree because<br /> ext4_mb_discard_group_preallocation() can paralelly mark the pa deleted<br /> and that can cause direct traversal to skip some entries. This was<br /> leading to a BUG_ON() being hit [1] when we missed a PA that could satisfy<br /> our request and ultimately tried to create a new PA that would overlap<br /> with the missed one.<br /> <br /> To makes sure we handle that case while still keeping the performance of<br /> the rbtree, we make use of the fact that the only pa that could possibly<br /> overlap the original goal start is the one that satisfies the below<br /> conditions:<br /> <br /> 1. It must have it&amp;#39;s logical start immediately to the left of<br /> (ie less than) original logical start.<br /> <br /> 2. It must not be deleted<br /> <br /> To find this pa we use the following traversal method:<br /> <br /> 1. Descend into the rbtree normally to find the immediate neighboring<br /> PA. Here we keep descending irrespective of if the PA is deleted or if<br /> it overlaps with our request etc. The goal is to find an immediately<br /> adjacent PA.<br /> <br /> 2. If the found PA is on right of original goal, use rb_prev() to find<br /> the left adjacent PA.<br /> <br /> 3. Check if this PA is deleted and keep moving left with rb_prev() until<br /> a non deleted PA is found.<br /> <br /> 4. This is the PA we are looking for. Now we can check if it can satisfy<br /> the original request and proceed accordingly.<br /> <br /> This approach also takes care of having deleted PAs in the tree.<br /> <br /> (While we are at it, also fix a possible overflow bug in calculating the<br /> end of a PA)<br /> <br /> [1] https://lore.kernel.org/linux-ext4/CA+G9fYv2FRpLqBZf34ZinR8bU2_ZRAUOjKAD3+tKRFaEQHtt8Q@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PCI: Fix dropping valid root bus resources with .end = zero<br /> <br /> On r8a7791/koelsch:<br /> <br /> kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> # cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xc3a34e00 (size 64):<br /> comm "swapper/0", pid 1, jiffies 4294937460 (age 199.080s)<br /> hex dump (first 32 bytes):<br /> b4 5d 81 f0 b4 5d 81 f0 c0 b0 a2 c3 00 00 00 00 .]...]..........<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc+0xf0/0x140<br /> [] resource_list_create_entry+0x18/0x38<br /> [] pci_add_resource_offset+0x20/0x68<br /> [] devm_of_pci_get_host_bridge_resources.constprop.0+0xb0/0x390<br /> <br /> When coalescing two resources for a contiguous aperture, the second<br /> resource is enlarged to cover the full contiguous range, while the first<br /> resource is marked invalid. This invalidation is done by clearing the<br /> flags, start, and end members.<br /> <br /> When adding the initial resources to the bus later, invalid resources are<br /> skipped. Unfortunately, the check for an invalid resource considers only<br /> the end member, causing false positives.<br /> <br /> E.g. on r8a7791/koelsch, root bus resource 0 ("bus 00") is skipped, and no<br /> longer registered with pci_bus_insert_busn_res() (causing the memory leak),<br /> nor printed:<br /> <br /> pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:<br /> pci-rcar-gen2 ee090000.pci: MEM 0x00ee080000..0x00ee08ffff -&gt; 0x00ee080000<br /> pci-rcar-gen2 ee090000.pci: PCI: revision 11<br /> pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00<br /> -pci_bus 0000:00: root bus resource [bus 00]<br /> pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]<br /> <br /> Fix this by only skipping resources where all of the flags, start, and end<br /> members are zero.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-timers: Prevent RT livelock in itimer_delete()<br /> <br /> itimer_delete() has a retry loop when the timer is concurrently expired. On<br /> non-RT kernels this just spin-waits until the timer callback has completed,<br /> except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORK<br /> enabled.<br /> <br /> In that case and on RT kernels the existing task could live lock when<br /> preempting the task which does the timer delivery.<br /> <br /> Replace spin_unlock() with an invocation of timer_wait_running() to handle<br /> it the same way as the other retry loops in the posix timer code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: fix potential kgd_mem UAFs<br /> <br /> kgd_mem pointers returned by kfd_process_device_translate_handle are<br /> only guaranteed to be valid while p-&gt;mutex is held. As soon as the mutex<br /> is unlocked, another thread can free the BO.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()<br /> <br /> During NVMeTCP Authentication a controller can trigger a kernel<br /> oops by specifying the 8192 bit Diffie Hellman group and passing<br /> a correctly sized, but zeroed Diffie Hellamn value.<br /> mpi_cmp_ui() was detecting this if the second parameter was 0,<br /> but 1 is passed from dh_is_pubkey_valid(). This causes the null<br /> pointer u-&gt;d to be dereferenced towards the end of mpi_cmp_ui()

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ses: Fix slab-out-of-bounds in ses_enclosure_data_process()<br /> <br /> A fix for:<br /> <br /> BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x949/0xe30 [ses]<br /> Read of size 1 at addr ffff88a1b043a451 by task systemd-udevd/3271<br /> <br /> Checking after (and before in next loop) addl_desc_ptr[1] is sufficient, we<br /> expect the size to be sanitized before first access to addl_desc_ptr[1].<br /> Make sure we don&amp;#39;t walk beyond end of page.