Vulnerabilities

A vulnerability classified as critical has been found in SourceCodester Web-based Pharmacy Product Management System 1.0. This affects an unknown part of the component Login Handler. The manipulation of the argument login_email leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used.

A vulnerability classified as critical was found in SourceCodester Web-based Pharmacy Product Management System 1.0. This vulnerability affects unknown code of the file /search/search_stock. php. The manipulation of the argument Name leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

A vulnerability, which was classified as critical, has been found in SourceCodester Web-based Pharmacy Product Management System 1.0. This issue affects some unknown processing of the file /edit-product.php. The manipulation of the argument ID leads to sql injection. The attack may be initiated 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 /> cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update<br /> <br /> Check if policy is NULL before dereferencing it in amd_pstate_update.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watch_queue: fix pipe accounting mismatch<br /> <br /> Currently, watch_queue_set_size() modifies the pipe buffers charged to<br /> user-&gt;pipe_bufs without updating the pipe-&gt;nr_accounted on the pipe<br /> itself, due to the if (!pipe_has_watch_queue()) test in<br /> pipe_resize_ring(). This means that when the pipe is ultimately freed,<br /> we decrement user-&gt;pipe_bufs by something other than what than we had<br /> charged to it, potentially leading to an underflow. This in turn can<br /> cause subsequent too_many_pipe_buffers_soft() tests to fail with -EPERM.<br /> <br /> To remedy this, explicitly account for the pipe usage in<br /> watch_queue_set_size() to match the number set via account_pipe_buffers()<br /> <br /> (It&amp;#39;s unclear why watch_queue_set_size() does not update nr_accounted;<br /> it may be due to intentional overprovisioning in watch_queue_set_size()?)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: timer: Don&amp;#39;t take register_mutex with copy_from/to_user()<br /> <br /> The infamous mmap_lock taken in copy_from/to_user() can be often<br /> problematic when it&amp;#39;s called inside another mutex, as they might lead<br /> to deadlocks.<br /> <br /> In the case of ALSA timer code, the bad pattern is with<br /> guard(mutex)(&amp;register_mutex) that covers copy_from/to_user() -- which<br /> was mistakenly introduced at converting to guard(), and it had been<br /> carefully worked around in the past.<br /> <br /> This patch fixes those pieces simply by moving copy_from/to_user() out<br /> of the register mutex lock again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: int340x: Add NULL check for adev<br /> <br /> Not all devices have an ACPI companion fwnode, so adev might be NULL.<br /> This is similar to the commit cd2fd6eab480<br /> ("platform/x86: int3472: Check for adev == NULL").<br /> <br /> Add a check for adev not being set and return -ENODEV in that case to<br /> avoid a possible NULL pointer deref in int3402_thermal_probe().<br /> <br /> Note, under the same directory, int3400_thermal_probe() has such a<br /> check.<br /> <br /> [ rjw: Subject edit, added Fixes: ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RISC-V: KVM: Teardown riscv specific bits after kvm_exit<br /> <br /> During a module removal, kvm_exit invokes arch specific disable<br /> call which disables AIA. However, we invoke aia_exit before kvm_exit<br /> resulting in the following warning. KVM kernel module can&amp;#39;t be inserted<br /> afterwards due to inconsistent state of IRQ.<br /> <br /> [25469.031389] percpu IRQ 31 still enabled on CPU0!<br /> [25469.031732] WARNING: CPU: 3 PID: 943 at kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150<br /> [25469.031804] Modules linked in: kvm(-)<br /> [25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod Not tainted 6.14.0-rc5-06947-g91c763118f47-dirty #2<br /> [25469.031905] Hardware name: riscv-virtio,qemu (DT)<br /> [25469.031928] epc : __free_percpu_irq+0xa2/0x150<br /> [25469.031976] ra : __free_percpu_irq+0xa2/0x150<br /> [25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50<br /> [25469.032241] gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8<br /> [25469.032285] t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90<br /> [25469.032329] s1 : ff60000098b21080 a0 : 037d527a15eb4f00 a1 : 037d527a15eb4f00<br /> [25469.032372] a2 : 0000000000000023 a3 : 0000000000000001 a4 : ffffffff8122dbf8<br /> [25469.032410] a5 : 0000000000000fff a6 : 0000000000000000 a7 : ffffffff8122dc10<br /> [25469.032448] s2 : ff60000080c22eb0 s3 : 0000000200000022 s4 : 000000000000001f<br /> [25469.032488] s5 : ff60000080c22e00 s6 : ffffffff80c351c0 s7 : 0000000000000000<br /> [25469.032582] s8 : 0000000000000003 s9 : 000055556b7fb490 s10: 00007ffff0e12fa0<br /> [25469.032621] s11: 00007ffff0e13e9a t3 : ffffffff81354ac7 t4 : ffffffff81354ac7<br /> [25469.032664] t5 : ffffffff81354ac8 t6 : ffffffff81354ac7<br /> [25469.032698] status: 0000000200000100 badaddr: ffffffff8007db1e cause: 0000000000000003<br /> [25469.032738] [] __free_percpu_irq+0xa2/0x150<br /> [25469.032797] [] free_percpu_irq+0x30/0x5e<br /> [25469.032856] [] kvm_riscv_aia_exit+0x40/0x42 [kvm]<br /> [25469.033947] [] cleanup_module+0x10/0x32 [kvm]<br /> [25469.035300] [] __riscv_sys_delete_module+0x18e/0x1fc<br /> [25469.035374] [] syscall_handler+0x3a/0x46<br /> [25469.035456] [] do_trap_ecall_u+0x72/0x134<br /> [25469.035536] [] handle_exception+0x148/0x156<br /> <br /> Invoke aia_exit and other arch specific cleanup functions after kvm_exit<br /> so that disable gets a chance to be called first before exit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: update channel list in reg notifier instead reg worker<br /> <br /> Currently when ath11k gets a new channel list, it will be processed<br /> according to the following steps:<br /> 1. update new channel list to cfg80211 and queue reg_work.<br /> 2. cfg80211 handles new channel list during reg_work.<br /> 3. update cfg80211&amp;#39;s handled channel list to firmware by<br /> ath11k_reg_update_chan_list().<br /> <br /> But ath11k will immediately execute step 3 after reg_work is just<br /> queued. Since step 2 is asynchronous, cfg80211 may not have completed<br /> handling the new channel list, which may leading to an out-of-bounds<br /> write error:<br /> BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list<br /> Call Trace:<br /> ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]<br /> kfree+0x109/0x3a0<br /> ath11k_regd_update+0x1cf/0x350 [ath11k]<br /> ath11k_regd_update_work+0x14/0x20 [ath11k]<br /> process_one_work+0xe35/0x14c0<br /> <br /> Should ensure step 2 is completely done before executing step 3. Thus<br /> Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,<br /> cfg80211 will notify ath11k after step 2 is done.<br /> <br /> So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will<br /> notify ath11k after step 2 is done. At this time, there will be no<br /> KASAN bug during the execution of the step 3.<br /> <br /> [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: quota: fix to avoid warning in dquot_writeback_dquots()<br /> <br /> F2FS-fs (dm-59): checkpoint=enable has some unwritten data.<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 6 PID: 8013 at fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308<br /> pc : dquot_writeback_dquots+0x2fc/0x308<br /> lr : f2fs_quota_sync+0xcc/0x1c4<br /> Call trace:<br /> dquot_writeback_dquots+0x2fc/0x308<br /> f2fs_quota_sync+0xcc/0x1c4<br /> f2fs_write_checkpoint+0x3d4/0x9b0<br /> f2fs_issue_checkpoint+0x1bc/0x2c0<br /> f2fs_sync_fs+0x54/0x150<br /> f2fs_do_sync_file+0x2f8/0x814<br /> __f2fs_ioctl+0x1960/0x3244<br /> f2fs_ioctl+0x54/0xe0<br /> __arm64_sys_ioctl+0xa8/0xe4<br /> invoke_syscall+0x58/0x114<br /> <br /> checkpoint and f2fs_remount may race as below, resulting triggering warning<br /> in dquot_writeback_dquots().<br /> <br /> atomic write remount<br /> - do_remount<br /> - down_write(&amp;sb-&gt;s_umount);<br /> - f2fs_remount<br /> - ioctl<br /> - f2fs_do_sync_file<br /> - f2fs_sync_fs<br /> - f2fs_write_checkpoint<br /> - block_operations<br /> - locked = down_read_trylock(&amp;sbi-&gt;sb-&gt;s_umount)<br /> : fail to lock due to the write lock was held by remount<br /> - up_write(&amp;sb-&gt;s_umount);<br /> - f2fs_quota_sync<br /> - dquot_writeback_dquots<br /> - WARN_ON_ONCE(!rwsem_is_locked(&amp;sb-&gt;s_umount))<br /> : trigger warning because s_umount lock was unlocked by remount<br /> <br /> If checkpoint comes from mount/umount/remount/freeze/quotactl, caller of<br /> checkpoint has already held s_umount lock, calling dquot_writeback_dquots()<br /> in the context should be safe.<br /> <br /> So let&amp;#39;s record task to sbi-&gt;umount_lock_holder, so that checkpoint can<br /> know whether the lock has held in the context or not by checking current<br /> w/ it.<br /> <br /> In addition, in order to not misrepresent caller of checkpoint, we should<br /> not allow to trigger async checkpoint for those callers: mount/umount/remount/<br /> freeze/quotactl.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: prevent NPD when writing a positive value to event_done<br /> <br /> do_uevent returns the value written to event_done. In case it is a<br /> positive value, new_lockspace would undo all the work, and lockspace<br /> would not be set. __dlm_new_lockspace, however, would treat that<br /> positive value as a success due to commit 8511a2728ab8 ("dlm: fix use<br /> count with multiple joins").<br /> <br /> Down the line, device_create_lockspace would pass that NULL lockspace to<br /> dlm_find_lockspace_local, leading to a NULL pointer dereference.<br /> <br /> Treating such positive values as successes prevents the problem. Given<br /> this has been broken for so long, this is unlikely to break userspace<br /> expectations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid panic once fallocation fails for pinfile<br /> <br /> syzbot reports a f2fs bug as below:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/f2fs/segment.c:2746!<br /> CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0<br /> RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline]<br /> RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876<br /> Call Trace:<br /> <br /> __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210<br /> f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline]<br /> f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238<br /> f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830<br /> f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940<br /> vfs_fallocate+0x569/0x6e0 fs/open.c:327<br /> do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885<br /> __do_sys_ioctl fs/ioctl.c:904 [inline]<br /> __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Concurrent pinfile allocation may run out of free section, result in<br /> panic in get_new_segment(), let&amp;#39;s expand pin_sem lock coverage to<br /> include f2fs_gc(), so that we can make sure to reclaim enough free<br /> space for following allocation.<br /> <br /> In addition, do below changes to enhance error path handling:<br /> - call f2fs_bug_on() only in non-pinfile allocation path in<br /> get_new_segment().<br /> - call reset_curseg_fields() to reset all fields of curseg in<br /> new_curseg()