Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: Fix UAF of leds class devs at unbinding<br /> <br /> The LED class devices that are created by HD-audio codec drivers are<br /> registered via devm_led_classdev_register() and associated with the<br /> HD-audio codec device. Unfortunately, it turned out that the devres<br /> release doesn&amp;#39;t work for this case; namely, since the codec resource<br /> release happens before the devm call chain, it triggers a NULL<br /> dereference or a UAF for a stale set_brightness_delay callback.<br /> <br /> For fixing the bug, this patch changes the LED class device register<br /> and unregister in a manual manner without devres, keeping the<br /> instances in hda_gen_spec.

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 /> btrfs: fix use-after-free after failure to create a snapshot<br /> <br /> At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and<br /> then attach it to the transaction&amp;#39;s list of pending snapshots. After that<br /> we call btrfs_commit_transaction(), and if that returns an error we jump<br /> to &amp;#39;fail&amp;#39; label, where we kfree() the pending snapshot structure. This can<br /> result in a later use-after-free of the pending snapshot:<br /> <br /> 1) We allocated the pending snapshot and added it to the transaction&amp;#39;s<br /> list of pending snapshots;<br /> <br /> 2) We call btrfs_commit_transaction(), and it fails either at the first<br /> call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().<br /> In both cases, we don&amp;#39;t abort the transaction and we release our<br /> transaction handle. We jump to the &amp;#39;fail&amp;#39; label and free the pending<br /> snapshot structure. We return with the pending snapshot still in the<br /> transaction&amp;#39;s list;<br /> <br /> 3) Another task commits the transaction. This time there&amp;#39;s no error at<br /> all, and then during the transaction commit it accesses a pointer<br /> to the pending snapshot structure that the snapshot creation task<br /> has already freed, resulting in a user-after-free.<br /> <br /> This issue could actually be detected by smatch, which produced the<br /> following warning:<br /> <br /> fs/btrfs/ioctl.c:843 create_snapshot() warn: &amp;#39;&amp;pending_snapshot-&gt;list&amp;#39; not removed from list<br /> <br /> So fix this by not having the snapshot creation ioctl directly add the<br /> pending snapshot to the transaction&amp;#39;s list. Instead add the pending<br /> snapshot to the transaction handle, and then at btrfs_commit_transaction()<br /> we add the snapshot to the list only when we can guarantee that any error<br /> returned after that point will result in a transaction abort, in which<br /> case the ioctl code can safely free the pending snapshot and no one can<br /> access it anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> isdn: cpai: check ctr-&gt;cnr to avoid array index out of bound<br /> <br /> The cmtp_add_connection() would add a cmtp session to a controller<br /> and run a kernel thread to process cmtp.<br /> <br /> __module_get(THIS_MODULE);<br /> session-&gt;task = kthread_run(cmtp_session, session, "kcmtpd_ctr_%d",<br /> session-&gt;num);<br /> <br /> During this process, the kernel thread would call detach_capi_ctr()<br /> to detach a register controller. if the controller<br /> was not attached yet, detach_capi_ctr() would<br /> trigger an array-index-out-bounds bug.<br /> <br /> [ 46.866069][ T6479] UBSAN: array-index-out-of-bounds in<br /> drivers/isdn/capi/kcapi.c:483:21<br /> [ 46.867196][ T6479] index -1 is out of range for type &amp;#39;capi_ctr *[32]&amp;#39;<br /> [ 46.867982][ T6479] CPU: 1 PID: 6479 Comm: kcmtpd_ctr_0 Not tainted<br /> 5.15.0-rc2+ #8<br /> [ 46.869002][ T6479] Hardware name: QEMU Standard PC (i440FX + PIIX,<br /> 1996), BIOS 1.14.0-2 04/01/2014<br /> [ 46.870107][ T6479] Call Trace:<br /> [ 46.870473][ T6479] dump_stack_lvl+0x57/0x7d<br /> [ 46.870974][ T6479] ubsan_epilogue+0x5/0x40<br /> [ 46.871458][ T6479] __ubsan_handle_out_of_bounds.cold+0x43/0x48<br /> [ 46.872135][ T6479] detach_capi_ctr+0x64/0xc0<br /> [ 46.872639][ T6479] cmtp_session+0x5c8/0x5d0<br /> [ 46.873131][ T6479] ? __init_waitqueue_head+0x60/0x60<br /> [ 46.873712][ T6479] ? cmtp_add_msgpart+0x120/0x120<br /> [ 46.874256][ T6479] kthread+0x147/0x170<br /> [ 46.874709][ T6479] ? set_kthread_struct+0x40/0x40<br /> [ 46.875248][ T6479] ret_from_fork+0x1f/0x30<br /> [ 46.875773][ T6479]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping()<br /> <br /> After commit e3beca48a45b ("irqdomain/treewide: Keep firmware node<br /> unconditionally allocated"). For tear down scenario, fn is only freed<br /> after fail to allocate ir_domain, though it also should be freed in case<br /> dmar_enable_qi returns error.<br /> <br /> Besides free fn, irq_domain and ir_msi_domain need to be removed as well<br /> if intel_setup_irq_remapping fails to enable queued invalidation.<br /> <br /> Improve the rewinding path by add out_free_ir_domain and out_free_fwnode<br /> lables per Baolu&amp;#39;s suggestion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: Fix refcounting leak in siw_create_qp()<br /> <br /> The atomic_inc() needs to be paired with an atomic_dec() on the error<br /> path.

A vulnerability was found in LabVantage LIMS 2017. It has been rated as problematic. This issue affects some unknown processing of the file /labvantage/rc?command=page&amp;page=LV_ViewSampleSpec&amp;oosonly=Y&amp;_sdialog=Y. The manipulation of the argument sdcid/keyid1 leads to cross site scripting. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-269153 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

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

The Sina Extension for Elementor (Slider, Gallery, Form, Modal, Data Table, Tab, Particle, Free Elementor Widgets &amp; Elementor Templates) plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘url’ parameter in all versions up to, and including, 3.5.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

A vulnerability was found in LabVantage LIMS 2017. It has been declared as problematic. This vulnerability affects unknown code of the file /labvantage/rc?command=file&amp;file=WEB-CORE/elements/files/filesembedded.jsp&amp;size=32. The manipulation of the argument height/width leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-269152. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Use VM_MAP instead of VM_ALLOC for ringbuf<br /> <br /> After commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pages<br /> after mapping"), non-VM_ALLOC mappings will be marked as accessible<br /> in __get_vm_area_node() when KASAN is enabled. But now the flag for<br /> ringbuf area is VM_ALLOC, so KASAN will complain out-of-bound access<br /> after vmap() returns. Because the ringbuf area is created by mapping<br /> allocated pages, so use VM_MAP instead.<br /> <br /> After the change, info in /proc/vmallocinfo also changes from<br /> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc user<br /> to<br /> [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: bnx2fc: Make bnx2fc_recv_frame() mp safe<br /> <br /> Running tests with a debug kernel shows that bnx2fc_recv_frame() is<br /> modifying the per_cpu lport stats counters in a non-mpsafe way. Just boot<br /> a debug kernel and run the bnx2fc driver with the hardware enabled.<br /> <br /> [ 1391.699147] BUG: using smp_processor_id() in preemptible [00000000] code: bnx2fc_<br /> [ 1391.699160] caller is bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]<br /> [ 1391.699174] CPU: 2 PID: 4355 Comm: bnx2fc_l2_threa Kdump: loaded Tainted: G B<br /> [ 1391.699180] Hardware name: HP ProLiant DL120 G7, BIOS J01 07/01/2013<br /> [ 1391.699183] Call Trace:<br /> [ 1391.699188] dump_stack_lvl+0x57/0x7d<br /> [ 1391.699198] check_preemption_disabled+0xc8/0xd0<br /> [ 1391.699205] bnx2fc_recv_frame+0xbf9/0x1760 [bnx2fc]<br /> [ 1391.699215] ? do_raw_spin_trylock+0xb5/0x180<br /> [ 1391.699221] ? bnx2fc_npiv_create_vports.isra.0+0x4e0/0x4e0 [bnx2fc]<br /> [ 1391.699229] ? bnx2fc_l2_rcv_thread+0xb7/0x3a0 [bnx2fc]<br /> [ 1391.699240] bnx2fc_l2_rcv_thread+0x1af/0x3a0 [bnx2fc]<br /> [ 1391.699250] ? bnx2fc_ulp_init+0xc0/0xc0 [bnx2fc]<br /> [ 1391.699258] kthread+0x364/0x420<br /> [ 1391.699263] ? _raw_spin_unlock_irq+0x24/0x50<br /> [ 1391.699268] ? set_kthread_struct+0x100/0x100<br /> [ 1391.699273] ret_from_fork+0x22/0x30<br /> <br /> Restore the old get_cpu/put_cpu code with some modifications to reduce the<br /> size of the critical section.