Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix deinitialization of firmware resources<br /> <br /> Currently, in ath11k_ahb_fw_resources_init(), iommu domain<br /> mapping is done only for the chipsets having fixed firmware<br /> memory. Also, for such chipsets, mapping is done only if it<br /> does not have TrustZone support.<br /> <br /> During deinitialization, only if TrustZone support is not there,<br /> iommu is unmapped back. However, for non fixed firmware memory<br /> chipsets, TrustZone support is not there and this makes the<br /> condition check to true and it tries to unmap the memory which<br /> was not mapped during initialization.<br /> <br /> This leads to the following trace -<br /> <br /> [ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> [ 83.259537] Modules linked in: ath11k_ahb ath11k qmi_helpers<br /> .. snip ..<br /> [ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 83.287228] pc : __iommu_unmap+0x30/0x140<br /> [ 83.293907] lr : iommu_unmap+0x5c/0xa4<br /> [ 83.298072] sp : ffff80000b3abad0<br /> .. snip ..<br /> [ 83.369175] Call trace:<br /> [ 83.376282] __iommu_unmap+0x30/0x140<br /> [ 83.378541] iommu_unmap+0x5c/0xa4<br /> [ 83.382360] ath11k_ahb_fw_resource_deinit.part.12+0x2c/0xac [ath11k_ahb]<br /> [ 83.385666] ath11k_ahb_free_resources+0x140/0x17c [ath11k_ahb]<br /> [ 83.392521] ath11k_ahb_shutdown+0x34/0x40 [ath11k_ahb]<br /> [ 83.398248] platform_shutdown+0x20/0x2c<br /> [ 83.403455] device_shutdown+0x16c/0x1c4<br /> [ 83.407621] kernel_restart_prepare+0x34/0x3c<br /> [ 83.411529] kernel_restart+0x14/0x74<br /> [ 83.415781] __do_sys_reboot+0x1c4/0x22c<br /> [ 83.419427] __arm64_sys_reboot+0x1c/0x24<br /> [ 83.423420] invoke_syscall+0x44/0xfc<br /> [ 83.427326] el0_svc_common.constprop.3+0xac/0xe8<br /> [ 83.430974] do_el0_svc+0xa0/0xa8<br /> [ 83.435659] el0_svc+0x1c/0x44<br /> [ 83.438957] el0t_64_sync_handler+0x60/0x144<br /> [ 83.441910] el0t_64_sync+0x15c/0x160<br /> [ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0)<br /> [ 83.449903] ---[ end trace 0000000000000000 ]---<br /> <br /> This can be reproduced by probing an AHB chipset which is not<br /> having a fixed memory region. During reboot (or rmmod) trace<br /> can be seen.<br /> <br /> Fix this issue by adding a condition check on firmware fixed memory<br /> hw_param as done in the counter initialization function.<br /> <br /> Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM / devfreq: Fix leak in devfreq_dev_release()<br /> <br /> srcu_init_notifier_head() allocates resources that need to be released<br /> with a srcu_cleanup_notifier_head() call.<br /> <br /> Reported by kmemleak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: pcie: Fix integer overflow in iwl_write_to_user_buf<br /> <br /> An integer overflow occurs in the iwl_write_to_user_buf() function,<br /> which is called by the iwl_dbgfs_monitor_data_read() function.<br /> <br /> static bool iwl_write_to_user_buf(char __user *user_buf, ssize_t count,<br /> void *buf, ssize_t *size,<br /> ssize_t *bytes_copied)<br /> {<br /> int buf_size_left = count - *bytes_copied;<br /> <br /> buf_size_left = buf_size_left - (buf_size_left % sizeof(u32));<br /> if (*size &gt; buf_size_left)<br /> *size = buf_size_left;<br /> <br /> If the user passes a SIZE_MAX value to the "ssize_t count" parameter,<br /> the ssize_t count parameter is assigned to "int buf_size_left".<br /> Then compare "*size" with "buf_size_left" . Here, "buf_size_left" is a<br /> negative number, so "*size" is assigned "buf_size_left" and goes into<br /> the third argument of the copy_to_user function, causing a heap overflow.<br /> <br /> This is not a security vulnerability because iwl_dbgfs_monitor_data_read()<br /> is a debugfs operation with 0400 privileges.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: fix time stamp counter initialization<br /> <br /> If the gs_usb device driver is unloaded (or unbound) before the<br /> interface is shut down, the USB stack first calls the struct<br /> usb_driver::disconnect and then the struct net_device_ops::ndo_stop<br /> callback.<br /> <br /> In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more<br /> RX&amp;#39;ed CAN frames are send from the USB device to the host. Later in<br /> gs_can_close() a reset control message is send to each CAN channel to<br /> remove the controller from the CAN bus. In this race window the USB<br /> device can still receive CAN frames from the bus and internally queue<br /> them to be send to the host.<br /> <br /> At least in the current version of the candlelight firmware, the queue<br /> of received CAN frames is not emptied during the reset command. After<br /> loading (or binding) the gs_usb driver, new URBs are submitted during<br /> the struct net_device_ops::ndo_open callback and the candlelight<br /> firmware starts sending its already queued CAN frames to the host.<br /> <br /> However, this scenario was not considered when implementing the<br /> hardware timestamp function. The cycle counter/time counter<br /> infrastructure is set up (gs_usb_timestamp_init()) after the USBs are<br /> submitted, resulting in a NULL pointer dereference if<br /> timecounter_cyc2time() (via the call chain:<br /> gs_usb_receive_bulk_callback() -&gt; gs_usb_set_timestamp() -&gt;<br /> gs_usb_skb_set_timestamp()) is called too early.<br /> <br /> Move the gs_usb_timestamp_init() function before the URBs are<br /> submitted to fix this problem.<br /> <br /> For a comprehensive solution, we need to consider gs_usb devices with<br /> more than 1 channel. The cycle counter/time counter infrastructure is<br /> setup per channel, but the RX URBs are per device. Once gs_can_open()<br /> of _a_ channel has been called, and URBs have been submitted, the<br /> gs_usb_receive_bulk_callback() can be called for _all_ available<br /> channels, even for channels that are not running, yet. As cycle<br /> counter/time counter has not set up, this will again lead to a NULL<br /> pointer dereference.<br /> <br /> Convert the cycle counter/time counter from a "per channel" to a "per<br /> device" functionality. Also set it up, before submitting any URBs to<br /> the device.<br /> <br /> Further in gs_usb_receive_bulk_callback(), don&amp;#39;t process any URBs for<br /> not started CAN channels, only resubmit the URB.