Vulnerabilities

fast-xml-parser is an open source, pure javascript xml parser. a ReDOS exists on currency.js. This vulnerability is fixed in 4.4.1.

Note Mark is a web-based Markdown notes app. A stored cross-site scripting (XSS) vulnerability in Note Mark allows attackers to execute arbitrary web scripts via a crafted payload injected into the URL value of a link in the markdown content. This vulnerability is fixed in 0.13.1.

Twisted is an event-based framework for internet applications, supporting Python 3.6+. The `twisted.web.util.redirectTo` function contains an HTML injection vulnerability. If application code allows an attacker to control the redirect URL this vulnerability may result in Reflected Cross-Site Scripting (XSS) in the redirect response HTML body. This vulnerability is fixed in 24.7.0rc1.

ImageMagick is a free and open-source software suite, used for editing and manipulating digital images. The `AppImage` version `ImageMagick` might use an empty path when setting `MAGICK_CONFIGURE_PATH` and `LD_LIBRARY_PATH` environment variables while executing, which might lead to arbitrary code execution by loading malicious configuration files or shared libraries in the current working directory while executing `ImageMagick`. The vulnerability is fixed in 7.11-36.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcachefs: Fix sb_field_downgrade validation<br /> <br /> - bch2_sb_downgrade_validate() wasn&amp;#39;t checking for a downgrade entry<br /> extending past the end of the superblock section<br /> <br /> - for_each_downgrade_entry() is used in to_text() and needs to work on<br /> malformed input; it also was missing a check for a field extending<br /> past the end of the section

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/fbdev-dma: Only set smem_start is enable per module option<br /> <br /> Only export struct fb_info.fix.smem_start if that is required by the<br /> user and the memory does not come from vmalloc().<br /> <br /> Setting struct fb_info.fix.smem_start breaks systems where DMA<br /> memory is backed by vmalloc address space. An example error is<br /> shown below.<br /> <br /> [ 3.536043] ------------[ cut here ]------------<br /> [ 3.540716] virt_to_phys used for non-linear address: 000000007fc4f540 (0xffff800086001000)<br /> [ 3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 __virt_to_phys+0x68/0x98<br /> [ 3.565455] Modules linked in:<br /> [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 6.6.23-06226-g4986cc3e1b75-dirty #250<br /> [ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT)<br /> [ 3.582452] Workqueue: events_unbound deferred_probe_work_func<br /> [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 3.595233] pc : __virt_to_phys+0x68/0x98<br /> [ 3.599246] lr : __virt_to_phys+0x68/0x98<br /> [ 3.603276] sp : ffff800083603990<br /> [ 3.677939] Call trace:<br /> [ 3.680393] __virt_to_phys+0x68/0x98<br /> [ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238<br /> [ 3.689214] __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0<br /> [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68<br /> [ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0<br /> [ 3.705161] drm_client_register+0x60/0xb0<br /> [ 3.709269] drm_fbdev_dma_setup+0x94/0x148<br /> <br /> Additionally, DMA memory is assumed to by contiguous in physical<br /> address space, which is not guaranteed by vmalloc().<br /> <br /> Resolve this by checking the module flag drm_leak_fbdev_smem when<br /> DRM allocated the instance of struct fb_info. Fbdev-dma then only<br /> sets smem_start only if required (via FBINFO_HIDE_SMEM_START). Also<br /> guarantee that the framebuffer is not located in vmalloc address<br /> space.

Incorrect access control in Himalaya Xiaoya nano smart speaker rom_version 1.6.96 allows a remote attacker to have an unspecified impact.

Buffer Overflow vulnerability in host-host NEUQ_board v.1.0 allows a remote attacker to cause a denial of service via the password.h component.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-core: Fix double free on error<br /> <br /> If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump<br /> to the err_out label, which will call devres_release_group().<br /> devres_release_group() will trigger a call to ata_host_release().<br /> ata_host_release() calls kfree(host), so executing the kfree(host) in<br /> ata_host_alloc() will lead to a double free:<br /> <br /> kernel BUG at mm/slub.c:553!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:kfree+0x2cf/0x2f0<br /> Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da<br /> RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246<br /> RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320<br /> RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0<br /> RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780<br /> R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006<br /> FS: 00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x6a/0x90<br /> ? kfree+0x2cf/0x2f0<br /> ? exc_invalid_op+0x50/0x70<br /> ? kfree+0x2cf/0x2f0<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? ata_host_alloc+0xf5/0x120 [libata]<br /> ? ata_host_alloc+0xf5/0x120 [libata]<br /> ? kfree+0x2cf/0x2f0<br /> ata_host_alloc+0xf5/0x120 [libata]<br /> ata_host_alloc_pinfo+0x14/0xa0 [libata]<br /> ahci_init_one+0x6c9/0xd20 [ahci]<br /> <br /> Ensure that we will not call kfree(host) twice, by performing the kfree()<br /> only if the devres_open_group() call failed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: mcp251xfd: fix infinite loop when xmit fails<br /> <br /> When the mcp251xfd_start_xmit() function fails, the driver stops<br /> processing messages, and the interrupt routine does not return,<br /> running indefinitely even after killing the running application.<br /> <br /> Error messages:<br /> [ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16<br /> [ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).<br /> ... and repeat forever.<br /> <br /> The issue can be triggered when multiple devices share the same SPI<br /> interface. And there is concurrent access to the bus.<br /> <br /> The problem occurs because tx_ring-&gt;head increments even if<br /> mcp251xfd_start_xmit() fails. Consequently, the driver skips one TX<br /> package while still expecting a response in<br /> mcp251xfd_handle_tefif_one().<br /> <br /> Resolve the issue by starting a workqueue to write the tx obj<br /> synchronously if err = -EBUSY. In case of another error, decrement<br /> tx_ring-&gt;head, remove skb from the echo stack, and drop the message.<br /> <br /> [mkl: use more imperative wording in patch description]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes<br /> <br /> In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is<br /> assigned to mode, which will lead to a possible NULL pointer dereference<br /> on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().<br /> Add a check to avoid null pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/gt: Fix potential UAF by revoke of fence registers<br /> <br /> CI has been sporadically reporting the following issue triggered by<br /> igt@i915_selftest@live@hangcheck on ADL-P and similar machines:<br /> <br /> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence<br /> ...<br /> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled<br /> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled<br /> [414.070354] Unable to pin Y-tiled fence; err:-4<br /> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active))<br /> ...<br /> [ 609.603992] ------------[ cut here ]------------<br /> [ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!<br /> [ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1<br /> [ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023<br /> [ 609.604010] Workqueue: i915 __i915_gem_free_work [i915]<br /> [ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]<br /> ...<br /> [ 609.604271] Call Trace:<br /> [ 609.604273] <br /> ...<br /> [ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915]<br /> [ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915]<br /> [ 609.604977] force_unbind+0x24/0xa0 [i915]<br /> [ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915]<br /> [ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915]<br /> [ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]<br /> [ 609.605440] process_scheduled_works+0x351/0x690<br /> ...<br /> <br /> In the past, there were similar failures reported by CI from other IGT<br /> tests, observed on other platforms.<br /> <br /> Before commit 63baf4f3d587 ("drm/i915/gt: Only wait for GPU activity<br /> before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for<br /> idleness of vma-&gt;active via fence_update(). That commit introduced<br /> vma-&gt;fence-&gt;active in order for the fence_update() to be able to wait<br /> selectively on that one instead of vma-&gt;active since only idleness of<br /> fence registers was needed. But then, another commit 0d86ee35097a<br /> ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to<br /> fence_update() in i915_vma_revoke_fence() with only fence_write(), and<br /> also added that GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active)) in front.<br /> No justification was provided on why we might then expect idleness of<br /> vma-&gt;fence-&gt;active without first waiting on it.<br /> <br /> The issue can be potentially caused by a race among revocation of fence<br /> registers on one side and sequential execution of signal callbacks invoked<br /> on completion of a request that was using them on the other, still<br /> processed in parallel to revocation of those fence registers. Fix it by<br /> waiting for idleness of vma-&gt;fence-&gt;active in i915_vma_revoke_fence().<br /> <br /> (cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)