Vulnerabilities

IBM QRadar SIEM 7.5 through 7.5.0 UP14 stores user credentials in configuration files in source control which can be read by an authenticated user.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pid: Add a judgment for ns null in pid_nr_ns<br /> <br /> __task_pid_nr_ns<br /> ns = task_active_pid_ns(current);<br /> pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);<br /> if (pid &amp;&amp; ns-&gt;level level) {<br /> <br /> Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.<br /> <br /> For example:<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058<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 /> user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000<br /> [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000<br /> pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : __task_pid_nr_ns+0x74/0xd0<br /> lr : __task_pid_nr_ns+0x24/0xd0<br /> sp : ffffffc08001bd10<br /> x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001<br /> x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31<br /> x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0<br /> x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000<br /> x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc<br /> x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800<br /> x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001<br /> x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449<br /> x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc<br /> x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0<br /> Call trace:<br /> __task_pid_nr_ns+0x74/0xd0<br /> ...<br /> __handle_irq_event_percpu+0xd4/0x284<br /> handle_irq_event+0x48/0xb0<br /> handle_fasteoi_irq+0x160/0x2d8<br /> generic_handle_domain_irq+0x44/0x60<br /> gic_handle_irq+0x4c/0x114<br /> call_on_irq_stack+0x3c/0x74<br /> do_interrupt_handler+0x4c/0x84<br /> el1_interrupt+0x34/0x58<br /> el1h_64_irq_handler+0x18/0x24<br /> el1h_64_irq+0x68/0x6c<br /> account_kernel_stack+0x60/0x144<br /> exit_task_stack_account+0x1c/0x80<br /> do_exit+0x7e4/0xaf8<br /> ...<br /> get_signal+0x7bc/0x8d8<br /> do_notify_resume+0x128/0x828<br /> el0_svc+0x6c/0x70<br /> el0t_64_sync_handler+0x68/0xbc<br /> el0t_64_sync+0x1a8/0x1ac<br /> Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception in interrupt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: verify orphan file size is not too big<br /> <br /> In principle orphan file can be arbitrarily large. However orphan replay<br /> needs to traverse it all and we also pin all its buffers in memory. Thus<br /> filesystems with absurdly large orphan files can lead to big amounts of<br /> memory consumed. Limit orphan file size to a sane value and also use<br /> kvmalloc() for allocating array of block descriptor structures to avoid<br /> large order allocations for sane but large orphan files.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop<br /> <br /> The cleanup loop was starting at the wrong array index, causing<br /> out-of-bounds access.<br /> Start the loop at the correct index for zero-indexed arrays to prevent<br /> accessing memory beyond the allocated array bounds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP<br /> <br /> When running as an SNP or TDX guest under KVM, force the legacy PCI hole,<br /> i.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC<br /> via a forced variable MTRR range.<br /> <br /> In most KVM-based setups, legacy devices such as the HPET and TPM are<br /> enumerated via ACPI. ACPI enumeration includes a Memory32Fixed entry, and<br /> optionally a SystemMemory descriptor for an OperationRegion, e.g. if the<br /> device needs to be accessed via a Control Method.<br /> <br /> If a SystemMemory entry is present, then the kernel&amp;#39;s ACPI driver will<br /> auto-ioremap the region so that it can be accessed at will. However, the<br /> ACPI spec doesn&amp;#39;t provide a way to enumerate the memory type of<br /> SystemMemory regions, i.e. there&amp;#39;s no way to tell software that a region<br /> must be mapped as UC vs. WB, etc. As a result, Linux&amp;#39;s ACPI driver always<br /> maps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.<br /> <br /> The dedicated device drivers however, e.g. the HPET driver and TPM driver,<br /> want to map their associated memory as UC or WC, as accessing PCI devices<br /> using WB is unsupported.<br /> <br /> On bare metal and non-CoCO, the conflicting requirements "work" as firmware<br /> configures the PCI hole (and other device memory) to be UC in the MTRRs.<br /> So even though the ACPI mappings request WB, they are forced to UC- in the<br /> kernel&amp;#39;s tracking due to the kernel properly handling the MTRR overrides,<br /> and thus are compatible with the drivers&amp;#39; requested WC/UC-.<br /> <br /> With force WB MTRRs on SNP and TDX guests, the ACPI mappings get their<br /> requested WB if the ACPI mappings are established before the dedicated<br /> driver code attempts to initialize the device. E.g. if acpi_init()<br /> runs before the corresponding device driver is probed, ACPI&amp;#39;s WB mapping<br /> will "win", and result in the driver&amp;#39;s ioremap() failing because the<br /> existing WB mapping isn&amp;#39;t compatible with the requested WC/UC-.<br /> <br /> E.g. when a TPM is emulated by the hypervisor (ignoring the security<br /> implications of relying on what is allegedly an untrusted entity to store<br /> measurements), the TPM driver will request UC and fail:<br /> <br /> [ 1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0<br /> [ 1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12<br /> <br /> Note, the &amp;#39;0x2&amp;#39; and &amp;#39;0x0&amp;#39; values refer to "enum page_cache_mode", not x86&amp;#39;s<br /> memtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).<br /> E.g. tracing mapping requests for TPM TIS yields:<br /> <br /> Mapping TPM TIS with req_type = 0<br /> WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460<br /> Modules linked in:<br /> CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.16.0-rc7+ #2 VOLUNTARY<br /> Tainted: [W]=WARN<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025<br /> RIP: 0010:memtype_reserve+0x2ab/0x460<br /> __ioremap_caller+0x16d/0x3d0<br /> ioremap_cache+0x17/0x30<br /> x86_acpi_os_ioremap+0xe/0x20<br /> acpi_os_map_iomem+0x1f3/0x240<br /> acpi_os_map_memory+0xe/0x20<br /> acpi_ex_system_memory_space_handler+0x273/0x440<br /> acpi_ev_address_space_dispatch+0x176/0x4c0<br /> acpi_ex_access_region+0x2ad/0x530<br /> acpi_ex_field_datum_io+0xa2/0x4f0<br /> acpi_ex_extract_from_field+0x296/0x3e0<br /> acpi_ex_read_data_from_field+0xd1/0x460<br /> acpi_ex_resolve_node_to_value+0x2ee/0x530<br /> acpi_ex_resolve_to_value+0x1f2/0x540<br /> acpi_ds_evaluate_name_path+0x11b/0x190<br /> acpi_ds_exec_end_op+0x456/0x960<br /> acpi_ps_parse_loop+0x27a/0xa50<br /> acpi_ps_parse_aml+0x226/0x600<br /> acpi_ps_execute_method+0x172/0x3e0<br /> acpi_ns_evaluate+0x175/0x5f0<br /> acpi_evaluate_object+0x213/0x490<br /> acpi_evaluate_integer+0x6d/0x140<br /> acpi_bus_get_status+0x93/0x150<br /> acpi_add_single_object+0x43a/0x7c0<br /> acpi_bus_check_add+0x149/0x3a0<br /> acpi_bus_check_add_1+0x16/0x30<br /> acpi_ns_walk_namespace+0x22c/0x360<br /> acpi_walk_namespace+0x15c/0x170<br /> acpi_bus_scan+0x1dd/0x200<br /> acpi_scan_init+0xe5/0x2b0<br /> acpi_init+0x264/0x5b0<br /> do_one_i<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: skcipher - Fix reqsize handling<br /> <br /> Commit afddce13ce81d ("crypto: api - Add reqsize to crypto_alg")<br /> introduced cra_reqsize field in crypto_alg struct to replace type<br /> specific reqsize fields. It looks like this was introduced specifically<br /> for ahash and acomp from the commit description as subsequent commits<br /> add necessary changes in these alg frameworks.<br /> <br /> However, this is being recommended for use in all crypto algs [1]<br /> instead of setting reqsize using crypto_*_set_reqsize(). Using<br /> cra_reqsize in skcipher algorithms, hence, causes memory<br /> corruptions and crashes as the underlying functions in the algorithm<br /> framework have not been updated to set the reqsize properly from<br /> cra_reqsize. [2]<br /> <br /> Add proper set_reqsize calls in the skcipher init function to<br /> properly initialize reqsize for these algorithms in the framework.<br /> <br /> [1]: https://lore.kernel.org/linux-crypto/aCL8BxpHr5OpT04k@gondor.apana.org.au/<br /> [2]: https://gist.github.com/Pratham-T/24247446f1faf4b7843e4014d5089f6b

FiberHome AN5506-04-FA firmware versions up to and including RP2631 and HG6245D prior to RP2602 contain a stack-based buffer overflow, as the HTTP service (&amp;#39;webs&amp;#39;) fails to enforce maximum lengths for Cookie header values. When a cookie longer than 511 bytes is processed, a stack buffer is overrun, leading to a crash or potential control of execution flow.

TEC-IT TBarCode version 11.15 contains a vulnerability in the TBarCode11.ocx ActiveX/OCX control&amp;#39;s licensing handling (INI-file based) that can be abused to cause remote creation of files on the host filesystem. Depending on where files can be created and which filenames are allowed, this can allow attackers to write files that lead to code execution or persistence under the context of the hosting process.

Ozeki SMS Gateway versions up to and including 10.3.208 contain a path traversal vulnerability. Successful exploitation allows an unauthenticated attacker to use URL-encoded traversal sequences to read arbitrary files from the underlying filesystem with the privileges of the gateway service, leading to disclosure of sensitive information.

Tinycontrol LAN Controller v3 (LK3) firmware versions up to 1.58a (hardware v3.8) contain a missing authentication vulnerability in the stm.cgi endpoint. A remote, unauthenticated attacker can send crafted requests to forcibly reboot the device or restore factory settings, leading to a denial of service and configuration loss.

DBLTek GoIP-1 firmware versions up to and including GHSFVT-1.1-67-5 contain a local file inclusion vulnerability. The device&amp;#39;s web server exposes handlers (`frame.html` and `frame.A100.html`) that accept a path parameter (`content` or `sidebar`) which is not properly validated or canonicalized. An attacker can supply directory-traversal sequences to cause the server to read and return arbitrary filesystem files that the webserver user can access. Other GoIP models and firmware versions are likely affected. Exploitation evidence was observed by the Shadowserver Foundation on 2024-03-21 UTC.

The Epson Stylus SX510W embedded web management service fails to properly handle consecutive ampersand characters in query parameters when accessing /PRESENTATION/HTML/TOP/INDEX.HTML. A remote attacker can send a malformed request that triggers improper input parsing or memory handling, resulting in the printer process shutting down or powering off, causing a denial of service condition.