Vulnerabilities

In Frappe ERPNext 15.57.5, the function get_rfq_containing_supplier() at erpnext/buying/doctype/request_for_quotation/request_for_quotation.py is vulnerable to SQL Injection, which allows an attacker to extract all information from databases by injecting SQL query via the txt parameter.

In Frappe ERPNext 15.57.5, the function get_material_requests_based_on_supplier() at erpnext/stock/doctype/material_request/material_request.py is vulnerable to SQL Injection, which allows an attacker to extract all information from databases by injecting a SQL query into the txt parameter.

Improper handling of symbolic links in the TeamViewer Full Client and Host for Windows — in versions prior to 15.70 of TeamViewer Remote and Tensor — allows an attacker with local, unprivileged access to a device lacking adequate malware protection to escalate privileges by spoofing the update file path. This may result in unauthorized access to sensitive information.

Stored Cross-Site Scripting (XSS) vulnerability in Issabel v5.0.0, consisting of a stored XSS due to a lack of proper validation of user input, through the 'email' parameter in '/index.php?menu=address_book'.

Stored Cross-Site Scripting (XSS) vulnerability in Issabel v5.0.0, consisting of a stored XSS due to a lack of proper validation of user input, through the 'numero_conferencia' parameter in '/index.php?menu=conferencia'.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: Fix memory leak in rtw88_usb<br /> <br /> Kmemleak shows the following leak arising from routine in the usb<br /> probe routine:<br /> <br /> unreferenced object 0xffff895cb29bba00 (size 512):<br /> comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s)<br /> hex dump (first 32 bytes):<br /> 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0...<br /> 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U......<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x90<br /> [] rtw_usb_probe+0x2f1/0x680 [rtw_usb]<br /> [] usb_probe_interface+0xdd/0x2e0 [usbcore]<br /> [] really_probe+0x18e/0x3d0<br /> [] __driver_probe_device+0x78/0x160<br /> [] driver_probe_device+0x1f/0x90<br /> [] __driver_attach+0xbf/0x1b0<br /> [] bus_for_each_dev+0x70/0xc0<br /> [] bus_add_driver+0x10e/0x210<br /> [] driver_register+0x55/0xf0<br /> [] usb_register_driver+0x88/0x140 [usbcore]<br /> [] do_one_initcall+0x43/0x210<br /> [] do_init_module+0x4a/0x200<br /> [] __do_sys_finit_module+0xac/0x120<br /> [] do_syscall_64+0x56/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The leak was verified to be real by unloading the driver, which resulted<br /> in a dangling pointer to the allocation.<br /> <br /> The allocated memory is freed in rtw_usb_intf_deinit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thunderbolt: Fix memory leak in tb_handle_dp_bandwidth_request()<br /> <br /> The memory allocated in tb_queue_dp_bandwidth_request() needs to be<br /> released once the request is handled to avoid leaking it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: fix poll request timeout handling<br /> <br /> When doing io_uring benchmark on /dev/nullb0, it&amp;#39;s easy to crash the<br /> kernel if poll requests timeout triggered, as reported by David. [1]<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> Workqueue: kblockd blk_mq_timeout_work<br /> RIP: 0010:null_timeout_rq+0x4e/0x91<br /> Call Trace:<br /> ? null_timeout_rq+0x4e/0x91<br /> blk_mq_handle_expired+0x31/0x4b<br /> bt_iter+0x68/0x84<br /> ? bt_tags_iter+0x81/0x81<br /> __sbitmap_for_each_set.constprop.0+0xb0/0xf2<br /> ? __blk_mq_complete_request_remote+0xf/0xf<br /> bt_for_each+0x46/0x64<br /> ? __blk_mq_complete_request_remote+0xf/0xf<br /> ? percpu_ref_get_many+0xc/0x2a<br /> blk_mq_queue_tag_busy_iter+0x14d/0x18e<br /> blk_mq_timeout_work+0x95/0x127<br /> process_one_work+0x185/0x263<br /> worker_thread+0x1b5/0x227<br /> <br /> This is indeed a race problem between null_timeout_rq() and null_poll().<br /> <br /> null_poll() null_timeout_rq()<br /> spin_lock(&amp;nq-&gt;poll_lock)<br /> list_splice_init(&amp;nq-&gt;poll_list, &amp;list)<br /> spin_unlock(&amp;nq-&gt;poll_lock)<br /> <br /> while (!list_empty(&amp;list))<br /> req = list_first_entry()<br /> list_del_init()<br /> ...<br /> blk_mq_add_to_batch()<br /> // req-&gt;rq_next = NULL<br /> spin_lock(&amp;nq-&gt;poll_lock)<br /> <br /> // rq-&gt;queuelist-&gt;next == NULL<br /> list_del_init(&amp;rq-&gt;queuelist)<br /> <br /> spin_unlock(&amp;nq-&gt;poll_lock)<br /> <br /> Fix these problems by setting requests state to MQ_RQ_COMPLETE under<br /> nq-&gt;poll_lock protection, in which null_timeout_rq() can safely detect<br /> this race and early return.<br /> <br /> Note this patch just fix the kernel panic when request timeout happen.<br /> <br /> [1] https://lore.kernel.org/all/3893581.1691785261@warthog.procyon.org.uk/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Allow UD qp_type to join multicast only<br /> <br /> As for multicast:<br /> - The SIDR is the only mode that makes sense;<br /> - Besides PS_UDP, other port spaces like PS_IB is also allowed, as it is<br /> UD compatible. In this case qkey also needs to be set [1].<br /> <br /> This patch allows only UD qp_type to join multicast, and set qkey to<br /> default if it&amp;#39;s not set, to fix an uninit-value error: the ib-&gt;rec.qkey<br /> field is accessed without being initialized.<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in cma_set_qkey drivers/infiniband/core/cma.c:510 [inline]<br /> BUG: KMSAN: uninit-value in cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570<br /> cma_set_qkey drivers/infiniband/core/cma.c:510 [inline]<br /> cma_make_mc_event+0xb73/0xe00 drivers/infiniband/core/cma.c:4570<br /> cma_iboe_join_multicast drivers/infiniband/core/cma.c:4782 [inline]<br /> rdma_join_multicast+0x2b83/0x30a0 drivers/infiniband/core/cma.c:4814<br /> ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479<br /> ucma_join_multicast+0x1e3/0x250 drivers/infiniband/core/ucma.c:1546<br /> ucma_write+0x639/0x6d0 drivers/infiniband/core/ucma.c:1732<br /> vfs_write+0x8ce/0x2030 fs/read_write.c:588<br /> ksys_write+0x28c/0x520 fs/read_write.c:643<br /> __do_sys_write fs/read_write.c:655 [inline]<br /> __se_sys_write fs/read_write.c:652 [inline]<br /> __ia32_sys_write+0xdb/0x120 fs/read_write.c:652<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:114 [inline]<br /> __do_fast_syscall_32+0x96/0xf0 arch/x86/entry/common.c:180<br /> do_fast_syscall_32+0x34/0x70 arch/x86/entry/common.c:205<br /> do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:248<br /> entry_SYSENTER_compat_after_hwframe+0x4d/0x5c<br /> <br /> Local variable ib.i created at:<br /> cma_iboe_join_multicast drivers/infiniband/core/cma.c:4737 [inline]<br /> rdma_join_multicast+0x586/0x30a0 drivers/infiniband/core/cma.c:4814<br /> ucma_process_join+0xa76/0xf60 drivers/infiniband/core/ucma.c:1479<br /> <br /> CPU: 0 PID: 29874 Comm: syz-executor.3 Not tainted 5.16.0-rc3-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> =====================================================<br /> <br /> [1] https://lore.kernel.org/linux-rdma/20220117183832.GD84788@nvidia.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: check &amp;#39;jh-&gt;b_transaction&amp;#39; before removing it from checkpoint<br /> <br /> Following process will corrupt ext4 image:<br /> Step 1:<br /> jbd2_journal_commit_transaction<br /> __jbd2_journal_insert_checkpoint(jh, commit_transaction)<br /> // Put jh into trans1-&gt;t_checkpoint_list<br /> journal-&gt;j_checkpoint_transactions = commit_transaction<br /> // Put trans1 into journal-&gt;j_checkpoint_transactions<br /> <br /> Step 2:<br /> do_get_write_access<br /> test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty<br /> __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2<br /> <br /> Step 3:<br /> drop_cache<br /> journal_shrink_one_cp_list<br /> jbd2_journal_try_remove_checkpoint<br /> if (!trylock_buffer(bh)) // lock bh, true<br /> if (buffer_dirty(bh)) // buffer is not dirty<br /> __jbd2_journal_remove_checkpoint(jh)<br /> // remove jh from trans1-&gt;t_checkpoint_list<br /> <br /> Step 4:<br /> jbd2_log_do_checkpoint<br /> trans1 = journal-&gt;j_checkpoint_transactions<br /> // jh is not in trans1-&gt;t_checkpoint_list<br /> jbd2_cleanup_journal_tail(journal) // trans1 is done<br /> <br /> Step 5: Power cut, trans2 is not committed, jh is lost in next mounting.<br /> <br /> Fix it by checking &amp;#39;jh-&gt;b_transaction&amp;#39; before remove it from checkpoint.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix unsafe drain work queue code<br /> <br /> If create_qp does not fully succeed it is possible for qp cleanup<br /> code to attempt to drain the send or recv work queues before the<br /> queues have been created causing a seg fault. This patch checks<br /> to see if the queues exist before attempting to drain them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()<br /> <br /> The following call trace was observed:<br /> <br /> localhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete<br /> localhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092<br /> localhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN "nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291"<br /> localhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]<br /> localhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G B W OE --------- --- 5.14.0-70.22.1.el9_0.x86_64+debug #1<br /> localhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022<br /> localhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]<br /> localhost kernel: Call Trace:<br /> localhost kernel: dump_stack_lvl+0x57/0x7d<br /> localhost kernel: check_preemption_disabled+0xc8/0xd0<br /> localhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]<br /> <br /> Use raw_smp_processor_id() instead of smp_processor_id().<br /> <br /> Also use queue_work() across the driver instead of queue_work_on() thus<br /> avoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.