Vulnerabilities

rabbitmq-c is a C-language AMQP client library for RabbitMQ. Prior to 0.16.0, a malicious AMQP server can send an undersized HEADER or METHOD frame during client login and cause unsigned size_t underflow in amqp_handle_input() in librabbitmq/amqp_connection.c. The parser subtracts HEADER_SIZE, fixed per-frame fields, and FOOTER_SIZE from state->target_size without first checking the minimum frame length. The wrapped encoded.len value is passed through amqp_decode_properties() to amqp_decode_table_internal(), where it defeats bounds checks and causes an out-of-bounds read and process crash. An on-path attacker can also trigger the issue when AMQP traffic is not protected by TLS with certificate validation. The demonstrated impact is denial of service, with no reliable memory disclosure or code execution shown. This issue is fixed in version 0.16.0.

MISP contains a vulnerability in its background job dispatch mechanism that allows remote code execution as the web user. Background job arguments are passed directly as the argv of the CakePHP console process. CakePHP&amp;#39;s ShellDispatcher::_parsePaths() scans the entire argv for path switches (-app, --app, -working, --working, -root, --root, -webroot, --webroot) and uses the following element as the application root. The events/contact endpoint passes user-controlled fields (message and person) into job arguments without validation. An attacker who can submit the contact form can set the person field to a reserved switch and the message field to a phar:// URI pointing to a malicious archive. The CakePHP bootstrap then includes Config/core.php from within that archive, executing attacker-controlled PHP code with the privileges of the web user. <br /> <br /> The vulnerability requires the ability to submit the events/contact form (or any other endpoint that forwards user input into background job arguments). No special timing or race condition is required; the attack is deterministic once the crafted parameters are accepted. The impact is full remote code execution in the context of the MISP web server process, allowing data exfiltration, persistence, and lateral movement within the host.

MISP contains a stored cross-site scripting (XSS) vulnerability in the Overmind theme&amp;#39;s statistics views. The event General card and the server/feed preview card constructed donut chart legend labels by directly concatenating object name or category keys into an innerHTML string without HTML-encoding. Because MISP object names are user-controllable by any authenticated user with sufficient permissions to create or modify such objects, an attacker could craft a name containing malicious markup. When any other user viewed the affected Overmind dashboard, the injected markup would be interpreted as live HTML/JavaScript in the victim&amp;#39;s browser, executing in the context of the MISP application origin. This could allow session hijacking, data exfiltration, or arbitrary actions performed on behalf of the victim. <br /> <br /> The vulnerability requires the attacker to have low-level authenticated access to create or rename an object whose name is rendered in the legend, and the victim to view the Overmind event or server preview page. No special browser conditions or race conditions are required.

SigNoz versions from 0.88.0 before 0.142.1 contain a SQL injection vulnerability in trace-funnel analytics endpoints that interpolate service_name and span_name fields into ClickHouse string literals without escaping. Authenticated attackers can inject SQL through funnel step definitions to execute arbitrary queries and read results in HTTP responses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: Do not treat master device as a duplicate target<br /> <br /> i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C<br /> device with the same PID as the reference device. The search can match<br /> master-&gt;this, causing the controller itself to be returned as a<br /> duplicate.<br /> <br /> Since the controller is not a target device, it cannot be a duplicate of<br /> one. Exclude master-&gt;this from matching so that the function only<br /> returns real duplicate target devices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i3c: master: Fix use-after-free of master-&gt;this<br /> <br /> sysfs attribute callbacks for the master controller device dereference<br /> master-&gt;this. However, master-&gt;this is freed in<br /> i3c_master_detach_free_devs() before the master device itself is<br /> released.<br /> <br /> As a result, sysfs accesses can dereference a freed master-&gt;this<br /> pointer, leading to a use-after-free.<br /> <br /> Keep master-&gt;this alive until i3c_masterdev_release(), which is called<br /> after the master device and its sysfs state are being torn down. Do not<br /> free master-&gt;this as part of the normal device detach path.<br /> <br /> On the error path in i3c_master_set_info(), reset master-&gt;this and<br /> bus.cur_master to NULL before freeing the allocated device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: dat: atomically update mac addresses<br /> <br /> When a MAC address is updated in batadv_dat_entry_add(), it is done using a<br /> simple copy function. A parallel reader might only see parts of this<br /> update. In worst case, the reader is transporting the half updated MAC<br /> address over the network or is creating an ARP response using it -<br /> poisoning the ARP cache.<br /> <br /> atomic64_t can be used to store the 48 bit of a mac address. A reader will<br /> then either see the old mac address or the new one - never a mixture of<br /> both.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvdimm: virtio_pmem: refcount requests for token lifetime<br /> <br /> KASAN reports slab-use-after-free in __wake_up_common():<br /> BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160<br /> Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0<br /> <br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted<br /> 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux<br /> 1.17.0-2-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6d/0xb0<br /> print_report+0x170/0x4e2<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> ? __virt_addr_valid+0x1dc/0x380<br /> kasan_report+0xbc/0xf0<br /> ? __wake_up_common+0x114/0x160<br /> ? __wake_up_common+0x114/0x160<br /> __wake_up_common+0x114/0x160<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> __wake_up+0x36/0x60<br /> virtio_pmem_host_ack+0x11d/0x3b0<br /> ? sched_balance_domains+0x29f/0xb00<br /> ? __pfx_virtio_pmem_host_ack+0x10/0x10<br /> ? _raw_spin_lock_irqsave+0x98/0x100<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> vring_interrupt+0x1c9/0x5e0<br /> ? __pfx_vp_interrupt+0x10/0x10<br /> vp_vring_interrupt+0x87/0x100<br /> ? __pfx_vp_interrupt+0x10/0x10<br /> __handle_irq_event_percpu+0x17f/0x550<br /> ? __pfx__raw_spin_lock+0x10/0x10<br /> handle_irq_event+0xab/0x1c0<br /> handle_fasteoi_irq+0x276/0xae0<br /> __common_interrupt+0x65/0x130<br /> common_interrupt+0x78/0xa0<br /> <br /> <br /> virtio_pmem_host_ack() wakes a request that has already been freed by the<br /> submitter.<br /> <br /> This happens when the request token is still reachable via the virtqueue,<br /> but virtio_pmem_flush() returns and frees it.<br /> <br /> Fix the token lifetime by refcounting struct virtio_pmem_request.<br /> virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an<br /> extra reference once the request is queued. The completion path drops the<br /> virtqueue reference, and the submitter drops its reference before<br /> returning.

HortusFox-Web prior to version 6.1 contains a remote code execution vulnerability that allows authenticated administrators to execute arbitrary OS commands as the web server user by abusing the Import/Export functionality. Attackers can leverage the Import/Export feature, which is intended solely for data portability, to deploy and execute malicious code on the underlying application server host.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/tegra241-cmdqv: Publish an LVCMDQ only after it is fully initialized<br /> <br /> tegra241_vintf_init_lvcmdq() stores the freshly allocated vcmdq pointer to<br /> the vintf-&gt;lvcmdqs[] array, before tegra241_vcmdq_alloc_smmu_cmdq() builds<br /> the vcmdq-&gt;cmdq. The error ISR dereferences that cmdq, so a latched LVCMDQ<br /> error (e.g. one inherited across a kexec) firing in this window would make<br /> tegra241_vintf0_handle_error() pass the still-zeroed arm_smmu_cmdq down to<br /> __arm_smmu_cmdq_skip_err(), dereferencing NULL queue register pointers.<br /> <br /> Drop the store from tegra241_vintf_init_lvcmdq() and publish the vcmdq at<br /> the end of the allocation instead, with an smp_store_release() that pairs<br /> with an smp_load_acquire() in the ISR, which can see a fully built LVCMDQ<br /> or NULL.<br /> <br /> The user-owned LVCMDQ allocation moves accordingly, publishing the vcmdq<br /> once tegra241_vcmdq_hw_init_user() succeeds, using a plain store since a<br /> user VINTF&amp;#39;s lvcmdqs[] has no lockless reader -- the error ISR only walks<br /> the VINTF0 array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9481/2: breakpoint: CFI breakpoints only on demand<br /> <br /> This removes the stub hw_breakpoint_cfi_handler() from ARM, making<br /> it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless<br /> CFI is actively used in the kernel.<br /> <br /> When not instrumenting with CFI, or when a breakpoint is issued in<br /> userspace, we fall through to return 1 from hw_breakpoint_pending()<br /> "unhandled fault" so userspace can make use of this breakpoint.<br /> <br /> Tested with LKDTM and this command line:<br /> echo CFI_FORWARD_PROTO &gt; /sys/kernel/debug/provoke-crash/DIRECT<br /> still works as expected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, s390: Clear fetch destination on faulting arena atomic<br /> <br /> Same missing register clear as on riscv64. A RMW atomic on an arena pointer<br /> is converted to BPF_PROBE_ATOMIC and gets an exception table entry, but<br /> bpf_jit_probe_atomic_pre() only fills in the arena base and the probe<br /> offset, leaving probe-&gt;reg at the -1 that bpf_jit_probe_init() set, which<br /> bpf_jit_probe_post() writes into the entry and ex_handler_bpf() then reads<br /> back as "there is nothing to clear".<br /> <br /> That is right for a plain BPF_{ADD,AND,OR,XOR}, which only writes memory,<br /> but an RMW carrying BPF_FETCH also reads the old value into a register:<br /> src_reg for BPF_{ADD,AND,OR,XOR} | BPF_FETCH and BPF_XCHG, and r0 for<br /> BPF_CMPXCHG. So on a fault over an unmapped arena page the program resumes<br /> at the landing pad with whatever that register held before the atomic<br /> instead of the 0 that every other BPF_PROBE_* access delivers.<br /> <br /> Fill probe-&gt;reg in from bpf_atomic_load_reg(). Unlike x86-64 and arm64,<br /> s390x does not report arena violations from its exception handler, so there<br /> is no access direction to correct here, only the missing register clear.