| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client's metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap.
Impact:
An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because telemetry.max.bytes bounds only the compressed size; lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a partial mitigation.
Resolution:
- From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default. |
| An Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in AccessManager in Juniper Networks Session Smart Router and Session Smart Conductor allows an attacker with config-write privileges to achieve arbitrary command execution as root in the YANG configuration. |
| vtenext before 25.02.2 contains a reflected cross-site scripting vulnerability in modules/Home/HomeWidgetBlockList.php that echoes unsanitized widgetId keys from the widgetInfoList JSON parameter. Attackers can induce a logged-in user to submit a crafted POST request with HTML in widgetId keys, executing JavaScript in the victim's vtenext session. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys address
On a Packard Bell Dot SC (Intel Atom N2600 model) there is a FPDT table
which contains invalid physical addresses, with high bits set which fall
outside the range of the CPU-s supported physical address range.
Calling acpi_os_map_memory() on such an invalid phys address leads to
the below WARN_ON in ioremap triggering resulting in an oops/stacktrace.
Add code to verify the physical address before calling acpi_os_map_memory()
to fix / avoid the oops.
[ 1.226900] ioremap: invalid physical address 3001000000000000
[ 1.226949] ------------[ cut here ]------------
[ 1.226962] WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f
[ 1.226996] Modules linked in:
[ 1.227016] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3+ #490
[ 1.227029] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013
[ 1.227038] RIP: 0010:__ioremap_caller.cold+0x43/0x5f
[ 1.227054] Code: 96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00
[ 1.227067] RSP: 0000:ffffb18c40033d60 EFLAGS: 00010286
[ 1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX: 0000000000000000
[ 1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff
[ 1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18
[ 1.227115] R10: 0000000000000003 R11: ffffffff99d62fe8 R12: 0000000000000008
[ 1.227124] R13: 0003001000000000 R14: 0000000000001000 R15: 3001000000000000
[ 1.227135] FS: 0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000
[ 1.227146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.227156] CR2: 0000000000000000 CR3: 0000000018c26000 CR4: 00000000000006e0
[ 1.227167] Call Trace:
[ 1.227176] <TASK>
[ 1.227185] ? acpi_os_map_iomem+0x1c9/0x1e0
[ 1.227215] ? kmem_cache_alloc_trace+0x187/0x370
[ 1.227254] acpi_os_map_iomem+0x1c9/0x1e0
[ 1.227288] acpi_init_fpdt+0xa8/0x253
[ 1.227308] ? acpi_debugfs_init+0x1f/0x1f
[ 1.227339] do_one_initcall+0x5a/0x300
[ 1.227406] ? rcu_read_lock_sched_held+0x3f/0x80
[ 1.227442] kernel_init_freeable+0x28b/0x2cc
[ 1.227512] ? rest_init+0x170/0x170
[ 1.227538] kernel_init+0x16/0x140
[ 1.227552] ret_from_fork+0x1f/0x30
[ 1.227639] </TASK>
[ 1.227647] irq event stamp: 186819
[ 1.227656] hardirqs last enabled at (186825): [<ffffffff98184a6e>] __up_console_sem+0x5e/0x70
[ 1.227672] hardirqs last disabled at (186830): [<ffffffff98184a53>] __up_console_sem+0x43/0x70
[ 1.227686] softirqs last enabled at (186576): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160
[ 1.227701] softirqs last disabled at (186569): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160
[ 1.227715] ---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix potential stack-out-of-bounds in brcmf_c_preinit_dcmds()
This patch fixes a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware
version string by memcpy() in brcmf_fil_iovar_data_get().
The patch ensures buf is null-terminated.
Found by a modified version of syzkaller.
[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3
[ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 47.601565][ T1897] ==================================================================
[ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0
[ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897
[ 47.604336][ T1897]
[ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131
[ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event
[ 47.607453][ T1897] Call Trace:
[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1
[ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334
[ 47.609009][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609434][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609863][ T1897] kasan_report.cold+0x83/0xdf
[ 47.610366][ T1897] ? strsep+0x1b2/0x1f0
[ 47.610882][ T1897] strsep+0x1b2/0x1f0
[ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0
[ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40
[ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0
[ 47.614704][ T1897] ? find_held_lock+0x2d/0x110
[ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260
[ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 47.616288][ T1897] brcmf_attach+0x246/0xd40
[ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0
[ 47.617280][ T1897] ? kmemdup+0x43/0x50
[ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690
[ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760
[ 47.619429][ T1897] ? usb_probe_device+0x250/0x250
[ 47.619950][ T1897] really_probe+0x205/0xb70
[ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.622209][ T1897] driver_probe_device+0x4e/0x150
[ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0
[ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0
[ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30
[ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160
[ 47.625437][ T1897] __device_attach+0x23f/0x3a0
[ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0
[ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0
[ 47.627057][ T1897] bus_probe_device+0x1da/0x290
[ 47.627557][ T1897] device_add+0xb7b/0x1eb0
[ 47.628027][ T1897] ? wait_for_completion+0x290/0x290
[ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0
[ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0
[ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0
[ 47.630385][ T1897] usb_probe_device+0xbb/0x250
[ 47.630927][ T1897] ? usb_suspend+0x590/0x590
[ 47.631397][ T1897] really_probe+0x205/0xb70
[ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.633002][
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
intel_th: msu: Fix vmalloced buffers
After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP") there's
a chance of DMA buffer getting allocated via vmalloc(), which messes up
the mmapping code:
> RIP: msc_mmap_fault [intel_th_msu]
> Call Trace:
> <TASK>
> __do_fault
> do_fault
...
Fix this by accounting for vmalloc possibility. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: debug: Fix potential buffer overflow by snprintf()
snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).
This patch replaces with a safer version, scnprintf() for papering
over such a potential issue. |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: entry: avoid kprobe recursion
The cortex_a76_erratum_1463225_debug_handler() function is called when
handling debug exceptions (and synchronous exceptions from BRK
instructions), and so is called when a probed function executes. If the
compiler does not inline cortex_a76_erratum_1463225_debug_handler(), it
can be probed.
If cortex_a76_erratum_1463225_debug_handler() is probed, any debug
exception or software breakpoint exception will result in recursive
exceptions leading to a stack overflow. This can be triggered with the
ftrace multiple_probes selftest, and as per the example splat below.
This is a regression caused by commit:
6459b8469753e9fe ("arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround")
... which removed the NOKPROBE_SYMBOL() annotation associated with the
function.
My intent was that cortex_a76_erratum_1463225_debug_handler() would be
inlined into its caller, el1_dbg(), which is marked noinstr and cannot
be probed. Mark cortex_a76_erratum_1463225_debug_handler() as
__always_inline to ensure this.
Example splat prior to this patch (with recursive entries elided):
| # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events
| # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events
| # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
| Insufficient stack space to handle exception!
| ESR: 0x0000000096000047 -- DABT (current EL)
| FAR: 0xffff800009cefff0
| Task stack: [0xffff800009cf0000..0xffff800009cf4000]
| IRQ stack: [0xffff800008000000..0xffff800008004000]
| Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0]
| CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2
| Hardware name: linux,dummy-virt (DT)
| pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : arm64_enter_el1_dbg+0x4/0x20
| lr : el1_dbg+0x24/0x5c
| sp : ffff800009cf0000
| x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000
| x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
| x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068
| x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000
| x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
| x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
| x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0
| x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000
| x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4
| x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040
| Kernel panic - not syncing: kernel stack overflow
| CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2
| Hardware name: linux,dummy-virt (DT)
| Call trace:
| dump_backtrace+0xe4/0x104
| show_stack+0x18/0x4c
| dump_stack_lvl+0x64/0x7c
| dump_stack+0x18/0x38
| panic+0x14c/0x338
| test_taint+0x0/0x2c
| panic_bad_stack+0x104/0x118
| handle_bad_stack+0x34/0x48
| __bad_stack+0x78/0x7c
| arm64_enter_el1_dbg+0x4/0x20
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| cortex_a76_erratum_1463225_debug_handler+0x0/0x34
...
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| cortex_a76_erratum_1463225_debug_handler+0x0/0x34
...
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| cortex_a76_erratum_1463225_debug_handler+0x0/0x34
| el1h_64_sync_handler+0x40/0x98
| el1h_64_sync+0x64/0x68
| do_el0_svc+0x0/0x28
| el0t_64_sync_handler+0x84/0xf0
| el0t_64_sync+0x18c/0x190
| Kernel Offset: disabled
| CPU features: 0x0080,00005021,19001080
| Memory Limit: none
| ---[ end Kernel panic - not syncing: kernel stack overflow ]---
With this patch, cortex_a76_erratum_1463225_debug_handler() is inlined
into el1_dbg(), and el1_dbg() cannot be probed:
| # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events
| sh: write error: No such file or directory
| # grep -w cortex_a76_errat
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
power: supply: core: Fix boundary conditions in interpolation
The functions power_supply_temp2resist_simple and power_supply_ocv2cap_simple
handle boundary conditions incorrectly.
The change was introduced in a4585ba2050f460f749bbaf2b67bd56c41e30283
("power: supply: core: Use library interpolation").
There are two issues: First, the lines "high = i - 1" and "high = i" in ocv2cap
have the wrong order compared to temp2resist. As a consequence, ocv2cap
sets high=-1 if ocv>table[0].ocv, which causes an out-of-bounds read.
Second, the logic of temp2resist is also not correct.
Consider the case table[] = {{20, 100}, {10, 80}, {0, 60}}.
For temp=5, we expect a resistance of 70% by interpolation.
However, temp2resist sets high=low=2 and returns 60. |
| In the Linux kernel, the following vulnerability has been resolved:
watch_queue: Actually free the watch
free_watch() does everything barring actually freeing the watch object. Fix
this by adding the missing kfree.
kmemleak produces a report something like the following. Note that as an
address can be seen in the first word, the watch would appear to have gone
through call_rcu().
BUG: memory leak
unreferenced object 0xffff88810ce4a200 (size 96):
comm "syz-executor352", pid 3605, jiffies 4294947473 (age 13.720s)
hex dump (first 32 bytes):
e0 82 48 0d 81 88 ff ff 00 00 00 00 00 00 00 00 ..H.............
80 a2 e4 0c 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8214e6cc>] kmalloc include/linux/slab.h:581 [inline]
[<ffffffff8214e6cc>] kzalloc include/linux/slab.h:714 [inline]
[<ffffffff8214e6cc>] keyctl_watch_key+0xec/0x2e0 security/keys/keyctl.c:1800
[<ffffffff8214ec84>] __do_sys_keyctl+0x3c4/0x490 security/keys/keyctl.c:2016
[<ffffffff84493a25>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84493a25>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae |
| Other issue in the SVG component. This vulnerability was fixed in Firefox 159 and Thunderbird 159. |
| In Zephyr's WireGuard subsystem (subsys/net/lib/wireguard), wg_process_data_message() in wg_crypto.c linearizes an inbound transport-data payload into a fixed pool buffer of CONFIG_WIREGUARD_BUF_LEN bytes before decryption. The call net_buf_linearize(buf->data, data_len, pkt->buffer, ..., data_len) passed the attacker-derived data_len as both the destination capacity and the copy length, defeating the function's internal len = min(len, dst_len) bound. data_len is derived from the received UDP datagram length and is only lower-bounded by wg_ctrl_recv() (no upper bound). When data_len exceeds CONFIG_WIREGUARD_BUF_LEN — e.g. when the buffer length is lowered below the link MTU, on links with MTU above the buffer size, or via reassembled IPv4/IPv6 fragments that exceed it — the underlying memcpy writes past the end of the pool buffer, an out-of-bounds write (CWE-787). The overflow occurs before the Poly1305 authentication check, so it requires only a valid receiver session index rather than a valid authenticator, and is reachable by a malicious or compromised peer (or an on-path attacker driving an established session) over the network, yielding remote memory corruption and at minimum a reliable denial of service. The defect was present in the WireGuard implementation shipped in Zephyr 4.4.0. The fix adds an explicit data_len > CONFIG_WIREGUARD_BUF_LEN rejection and corrects the linearize call to pass net_buf_max_len(buf) as the destination capacity. |
| FreeRDP before 3.32.2 does not check the product of surface dimensions in gdi_CreateSurface when handling an RDPGFX CREATE_SURFACE PDU, causing an integer wrap and heap buffer overflow on 32-bit builds and an approximately 4 GiB allocation on 64-bit builds. A malicious RDP server can send a CREATE_SURFACE PDU with width and height 32766 to a connecting client to corrupt heap memory or cause a denial of service. |
| FreeRDP before 3.32.2 has an out-of-bounds write in the proxy because rdp_read_bitmap_cache_v2_capability_set rejects only numCellCaches values above 5, yet the bitmap cache v2 cell array is later accessed at fixed indices 0 through 4. A client connecting to the proxy can declare fewer than five cell caches in its Confirm Active, causing heap corruption, heap data leakage to the backend, or a crash. |
| A flaw was found in evolution-data-server. Inconsistent comparison logic in the addressbook file backend allows a Flatpak application with D-Bus access to craft a malicious URI containing directory traversal sequences. This URI is stored without proper validation during contact creation or modification. Later, during contact deletion, the URI is processed with a less strict check, leading to the deletion of arbitrary files on the host filesystem. This could potentially include critical Flatpak override files. |
| FreeRDP before 3.32.2 has a heap out-of-bounds write in the planar codec because freerdp_bitmap_planar_context_reset commits new dimensions before buffer reallocation succeeds, and a failed ResetGraphics is only logged. A malicious RDP server can send an oversized ResetGraphics PDU, then a GFX PLANAR command, to corrupt client heap memory and crash the client. |
| A flaw was found in libdm. A local attacker could craft a malicious Logical Volume Manager (LVM) metadata configuration with deeply nested structures. This could lead to uncontrolled recursion in the libdm configuration file parser, exhausting the stack and causing any LVM command reading the metadata to crash. This vulnerability results in a Denial of Service (DoS) for affected systems. |
| A flaw was found in dbus-broker. When the process file-descriptor limit is reached, EMFILE/ENFILE errors during peer setup (notably SO_PEERPIDFD) are handled as fatal failures, causing the broker to exit. A local attacker who can open many connections to the user session bus can trigger this and deny service to the desktop session. Flatpak applications can reach the host session bus through the dbus proxy. |
| FreeRDP through 3.32.1 has a heap out-of-bounds write in the RDPGFX client because the delete_surface callback truncates surface hash keys to 16 bits, leaving the surface table inconsistent so HashTable_GetKeys writes past its allocated key array. A malicious or man-in-the-middle RDP server can exploit this by creating surfaceId 0xFFFF, closing the RDPGFX channel, sending repeated DELETESURFACE PDUs, and then sending ENDFRAME or RESETGRAPHICS. |
| FreeRDP before 3.32.2 contains a heap buffer overflow in transport_default_read_pdu when handling partial Early User Authorization reads during PROTOCOL_HYBRID_EX CredSSP. A malicious RDP server can split the four-byte EUA result into short reads that advance the stream pointer beyond the 16 KiB allocation, causing an out-of-bounds write and client denial of service. |
