Vulnerabilities

HHCL BigFix Service Management (SM) is affected by a Cross‑Site Request Forgery (CSRF) vulnerability. This could lead to unauthorized changes or exposure of sensitive data.

HCL BigFix Service Management (SM) application fails to strip EXIF metadata from uploaded images. This could lead to confidentiality and privacy risks if sensitive location information is unintentionally shared. .

HCL BigFix Service Management (SM) is affected by an Information Disclosure – Server Banner issue was identified. Exposed server banners may reveal software versions and system details, potentially aiding attackers in targeting known vulnerabilities.

Cross Site Scripting vulnerability in Juzaweb CMS v.5.0.0 allows a remote attacker via execute arbitrary code via a crafted script to the Add Banner Ads function

A security flaw has been discovered in FlowiseAI Flowise up to 3.0.12. Affected is the function Login of the file packages/server/src/enterprise/services/account.service.ts of the component API Response Handler. The manipulation results in information disclosure. The attack can be launched remotely. A high complexity level is associated with this attack. The exploitability is told to be difficult. You should upgrade the affected component.

Gazelle versions through 0.49 for Perl allows HTTP Request Smuggling via Improper Header Precedence.<br /> <br /> Gazelle incorrectly prioritizes "Content-Length" over "Transfer-Encoding: chunked" when both headers are present in an HTTP request. Per RFC 7230 3.3.3, Transfer-Encoding must take precedence.<br /> <br /> An attacker could exploit this to smuggle malicious HTTP requests via a front-end reverse proxy.

Apache::Session::Generate::ModUniqueId versions from 1.54 through 1.94 for Perl session ids are insecure.<br /> <br /> Apache::Session::Generate::ModUniqueId (added in version 1.54) uses the value of the UNIQUE_ID environment variable for the session id. The UNIQUE_ID variable is set by the Apache mod_unique_id plugin, which generates unique ids for the request. The id is based on the IPv4 address, the process id, the epoch time, a 16-bit counter and a thread index, with no obfuscation.<br /> <br /> The server IP is often available to the public, and if not available, can be guessed from previous session ids being issued. The process ids may also be guessed from previous session ids. The timestamp is easily guessed (and leaked in the HTTP Date response header).<br /> <br /> The purpose of mod_unique_id is to assign a unique id to requests so that events can be correlated in different logs. The id is not designed, nor is it suitable for security purposes.

A type confusion vulnerability in Qt SVG allows an attacker to cause an application crash via a crafted SVG image.<br /> <br /> <br /> <br /> When processing SVG marker references, the renderer retrieves a node by its id attribute and casts it to QSvgMarker* without verifying the node type. A non-marker element (such as a element) that references itself as a marker triggers an out-of-bounds heap read due to the object size difference between QSvgLine and QSvgMarker,<br /> followed by an endless recursion that bypasses the marker recursion <br /> guard through incorrect virtual dispatch. The result is an application <br /> crash (denial of service).<br /> <br /> <br /> <br /> This issue affects Qt SVG: <br /> from 6.7.0 before 6.8.8, from 6.9.0 before 6.11.1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> APEI/GHES: ensure that won&amp;#39;t go past CPER allocated record<br /> <br /> The logic at ghes_new() prevents allocating too large records, by<br /> checking if they&amp;#39;re bigger than GHES_ESTATUS_MAX_SIZE (currently, 64KB).<br /> Yet, the allocation is done with the actual number of pages from the<br /> CPER bios table location, which can be smaller.<br /> <br /> Yet, a bad firmware could send data with a different size, which might<br /> be bigger than the allocated memory, causing an OOPS:<br /> <br /> Unable to handle kernel paging request at virtual address fff00000f9b40000<br /> Mem abort info:<br /> ESR = 0x0000000096000007<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x07: level 3 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000<br /> CM = 0, WnR = 0, TnD = 0, TagAccess = 0<br /> GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> swapper pgtable: 4k pages, 52-bit VAs, pgdp=000000008ba16000<br /> [fff00000f9b40000] pgd=180000013ffff403, p4d=180000013fffe403, pud=180000013f85b403, pmd=180000013f68d403, pte=0000000000000000<br /> Internal error: Oops: 0000000096000007 [#1] SMP<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 303 Comm: kworker/0:1 Not tainted 6.19.0-rc1-00002-gda407d200220 #34 PREEMPT<br /> Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 02/02/2022<br /> Workqueue: kacpi_notify acpi_os_execute_deferred<br /> pstate: 214020c5 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : hex_dump_to_buffer+0x30c/0x4a0<br /> lr : hex_dump_to_buffer+0x328/0x4a0<br /> sp : ffff800080e13880<br /> x29: ffff800080e13880 x28: ffffac9aba86f6a8 x27: 0000000000000083<br /> x26: fff00000f9b3fffc x25: 0000000000000004 x24: 0000000000000004<br /> x23: ffff800080e13905 x22: 0000000000000010 x21: 0000000000000083<br /> x20: 0000000000000001 x19: 0000000000000008 x18: 0000000000000010<br /> x17: 0000000000000001 x16: 00000007c7f20fec x15: 0000000000000020<br /> x14: 0000000000000008 x13: 0000000000081020 x12: 0000000000000008<br /> x11: ffff800080e13905 x10: ffff800080e13988 x9 : 0000000000000000<br /> x8 : 0000000000000000 x7 : 0000000000000001 x6 : 0000000000000020<br /> x5 : 0000000000000030 x4 : 00000000fffffffe x3 : 0000000000000000<br /> x2 : ffffac9aba78c1c8 x1 : ffffac9aba76d0a8 x0 : 0000000000000008<br /> Call trace:<br /> hex_dump_to_buffer+0x30c/0x4a0 (P)<br /> print_hex_dump+0xac/0x170<br /> cper_estatus_print_section+0x90c/0x968<br /> cper_estatus_print+0xf0/0x158<br /> __ghes_print_estatus+0xa0/0x148<br /> ghes_proc+0x1bc/0x220<br /> ghes_notify_hed+0x5c/0xb8<br /> notifier_call_chain+0x78/0x148<br /> blocking_notifier_call_chain+0x4c/0x80<br /> acpi_hed_notify+0x28/0x40<br /> acpi_ev_notify_dispatch+0x50/0x80<br /> acpi_os_execute_deferred+0x24/0x48<br /> process_one_work+0x15c/0x3b0<br /> worker_thread+0x2d0/0x400<br /> kthread+0x148/0x228<br /> ret_from_fork+0x10/0x20<br /> Code: 6b14033f 540001ad a94707e2 f100029f (b8747b44)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Prevent that by taking the actual allocated are into account when<br /> checking for CPER length.<br /> <br /> [ rjw: Subject tweaks ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm: clear cloned request bio pointer when last clone bio completes<br /> <br /> Stale rq-&gt;bio values have been observed to cause double-initialization of<br /> cloned bios in request-based device-mapper targets, leading to<br /> use-after-free and double-free scenarios.<br /> <br /> One such case occurs when using dm-multipath on top of a PCIe NVMe<br /> namespace, where cloned request bios are freed during<br /> blk_complete_request(), but rq-&gt;bio is left intact. Subsequent clone<br /> teardown then attempts to free the same bios again via<br /> blk_rq_unprep_clone().<br /> <br /> The resulting double-free path looks like:<br /> <br /> nvme_pci_complete_batch()<br /> nvme_complete_batch()<br /> blk_mq_end_request_batch()<br /> blk_complete_request() // called on a DM clone request<br /> bio_endio() // first free of all clone bios<br /> ...<br /> rq-&gt;end_io() // end_clone_request()<br /> dm_complete_request(tio-&gt;orig)<br /> dm_softirq_done()<br /> dm_done()<br /> dm_end_request()<br /> blk_rq_unprep_clone() // second free of clone bios<br /> <br /> Fix this by clearing the clone request&amp;#39;s bio pointer when the last cloned<br /> bio completes, ensuring that later teardown paths do not attempt to free<br /> already-released bios.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Add sanity check for OOB writes at silencing<br /> <br /> At silencing the playback URB packets in the implicit fb mode before<br /> the actual playback, we blindly assume that the received packets fit<br /> with the buffer size. But when the setup in the capture stream<br /> differs from the playback stream (e.g. due to the USB core limitation<br /> of max packet size), such an inconsistency may lead to OOB writes to<br /> the buffer, resulting in a crash.<br /> <br /> For addressing it, add a sanity check of the transfer buffer size at<br /> prepare_silent_urb(), and stop the data copy if the received data<br /> overflows. Also, report back the transfer error properly from there,<br /> too.<br /> <br /> Note that this doesn&amp;#39;t fix the root cause of the playback error<br /> itself, but this merely covers the kernel Oops.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Add bounds check on pat_index to prevent OOB kernel read in madvise<br /> <br /> When user provides a bogus pat_index value through the madvise IOCTL, the<br /> xe_pat_index_get_coh_mode() function performs an array access without<br /> validating bounds. This allows a malicious user to trigger an out-of-bounds<br /> kernel read from the xe-&gt;pat.table array.<br /> <br /> The vulnerability exists because the validation in madvise_args_are_sane()<br /> directly calls xe_pat_index_get_coh_mode(xe, args-&gt;pat_index.val) without<br /> first checking if pat_index is within [0, xe-&gt;pat.n_entries).<br /> <br /> Although xe_pat_index_get_coh_mode() has a WARN_ON to catch this in debug<br /> builds, it still performs the unsafe array access in production kernels.<br /> <br /> v2(Matthew Auld)<br /> - Using array_index_nospec() to mitigate spectre attacks when the value<br /> is used<br /> <br /> v3(Matthew Auld)<br /> - Put the declarations at the start of the block<br /> <br /> (cherry picked from commit 944a3329b05510d55c69c2ef455136e2fc02de29)