| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Scriban before 7.2.0 contains a denial of service vulnerability in the array.insert_at function that allocates unbounded null entries without respecting LoopLimit or LimitToString constraints. Attackers can supply a large index parameter to trigger OutOfMemoryException and crash the host process in under a second. |
| A denial-of-service and resource exhaustion vulnerability exists within the `GDBus` component of GLib. The `gdbusauth` authentication mechanism fails to enforce proper length limitations on data lines read from a client. An unauthenticated local or remote attacker can exploit this lack of input validation by sending excessively long streams of data, causing the application to consume massive amounts of system memory and CPU, potentially leading to a crash or system hang. |
| A weakness has been identified in GL.iNet A1300, AX1800, AXT1800, BE1400, BE3600, BE6500, BE9300, BE10000, E5800, MT2500, MT3000, MT3600BE, MT5000, MT6000, X2000, X3000 and XE3000 up to 4.8.x. This affects an unknown part of the component Wi-Fi Timer Power-Schedule Feature. Executing a manipulation of the argument switch_power/restore_power can lead to os command injection. The attack can be launched remotely. The vendor explains: "After our investigation, we have confirmed that the vulnerability described (...) does indeed exist." |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix insn_aux_data leak on verifier err_free_env path
When bpf_check() allocates env->insn_aux_data successfully but later
fails to allocate env->succ, it jumps directly to err_free_env.
The existing vfree(env->insn_aux_data) sits before the err_free_env
label, so that direct jump bypasses it and leaks insn_aux_data.
Move vfree(env->insn_aux_data) into err_free_env so all early and late
exit paths release it consistently. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/panthor: Fix a leak when a group is evicted before the tiler OOM is serviced
A group ref is tied to the pending tiler_oom_work, so we need to release
it if the cancel was effective. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: fix tx ident leak for commands without a response
Commit 6c3ea155e5ee ("Bluetooth: L2CAP: Fix not tracking outstanding
TX ident") changed ident allocation to use an IDA, releasing idents in
l2cap_put_ident() when the matching response command is received.
But identifiers allocated for commands that have no response defined
are never released. In particular L2CAP_LE_CREDITS is sent repeatedly for
the lifetime of an LE CoC channel, so a peer streaming data to the
host exhausts the 1-255 ident range after 254 credit packets. From
then on l2cap_get_ident() fails:
kernel: Bluetooth: Unable to allocate ident: -28
and every subsequent L2CAP_LE_CREDITS packet is sent with ident 0,
which is invalid (Core Spec, Vol 3, Part A, Section 4: "Signaling
identifier 0x00 is an invalid identifier and shall never be used in
any command"). Remote stacks that validate the ident drop these
commands, never receive new credits, and the channel stalls
permanently. With default socket buffers this happens after roughly 0.5 MB
of received data (the exact amount depends on the socket receive buffer):
< ACL Data TX: Handle 2048 flags 0x00 dlen 12
LE L2CAP: LE Flow Control Credit (0x16) ident 0 len 4
Source CID: 64
Credits: 1
Release the ident immediately after sending L2CAP_LE_CREDITS since no
response will ever release it. Use a local variable instead of
chan->ident so that an ident that an EXT_FLOWCTL channel may be waiting on
(e.g. a pending reconfigure) is not overwritten by a credit packet.
Also add the missing L2CAP_LE_CONN_RSP case to l2cap_put_ident() so
idents allocated for outgoing L2CAP_LE_CONN_REQ commands are released
when the response arrives. |
| In the Linux kernel, the following vulnerability has been resolved:
gpio: mvebu: free generic chips on unbind
irq_alloc_domain_generic_chips() allocates generic chip data that must
be freed via irq_domain_remove_generic_chips(). The devres action
mvebu_gpio_remove_irq_domain() only called irq_domain_remove(), which
only frees the generic chips if IRQ_DOMAIN_FLAG_DESTROY_GC is set.
Call irq_domain_remove_generic_chips() explicitly before
irq_domain_remove() instead. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/xe: free madvise VMA array on L2 flush failure
xe_vm_madvise_ioctl() allocates madvise_range.vmas in get_vmas().
After get_vmas() succeeds with at least one VMA, error paths must go
through free_vmas so the array is released before the madvise details are
destroyed.
The L2 flush validation path added for PAT madvise rejects some
SVM/userptr ranges after get_vmas() has succeeded, but jumps directly to
madv_fini. This skips kfree(madvise_range.vmas), leaking the VMA array on
each failed ioctl.
Jump to free_vmas instead, matching the other validation failure paths
after get_vmas() has succeeded.
(cherry picked from commit c3a1c3579b1250060da73507a4acef712974c78a) |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: metronomefb: fix potential memory leak in metronomefb_probe()
The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()
The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: hecubafb: fix potential memory leak in hecubafb_probe()
The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: efifb: fix memory leak in efifb_probe()
Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to
caller; clarify ownership") the string returned from fb_get_options()
is expected to be freed by the caller, but the string is not freed in
efifb_probe(). Fix that by freeing the option string after setup. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: radeon: fix potential memory leak in radeonfb_pci_register()
The function radeonfb_pci_register() allocates memory for modelist
(by calling radeon_check_modes() which calls fb_add_videomode()).
The memory is appended to info->modelist, but is not freed in subsequent
error paths. Fix this by calling fb_destroy_modelist(). |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()
In tdfxfb_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not
freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist(). |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()
The memory allocated for modelist in fb_videomode_to_modelist() is not
freed in the subsequent error path.
Fix that by calling fb_destroy_modelist() |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: vesafb: fix memory leak in vesafb_probe()
Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to
caller; clarify ownership") the string returned from fb_get_options()
is expected to be freed by the caller. But the string is not freed in
vesafb_probe(). Fix that by freeing the option string after setup. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: nvidia: fix potential memory leak in nvidiafb_probe()
In nvidiafb_probe(), the memory allocated for modelist in
nvidia_set_fbinfo() is not freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist(). |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8192: Check runtime resume during probe
The MT8192 AFE probe enables runtime PM temporarily while reinitializing
the regmap cache from hardware, but it uses pm_runtime_get_sync()
without checking the return value. If runtime resume fails, probe keeps
going without the device necessarily being accessible, and
pm_runtime_get_sync() may leave the PM usage count incremented.
The regmap_reinit_cache() failure path also returns before dropping the
temporary PM reference and before clearing pm_runtime_bypass_reg_ctl.
Use pm_runtime_resume_and_get() so resume failures do not leak a usage
count, and clear the temporary bypass flag after dropping the probe PM
reference on all regmap_reinit_cache() outcomes. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8183: Release reserved memory on cleanup
The MT8183 AFE probe can assign reserved memory with
of_reserved_mem_device_init(), but the assignment is never released on
driver removal or later probe failures.
Register a devm cleanup action so the reserved memory assignment is
released consistently, matching newer Mediatek AFE drivers. |
| In the Linux kernel, the following vulnerability has been resolved:
mfd: sm501: Fix reference leak on failed device registration
When platform_device_register() fails in sm501_register_device(), the
embedded struct device in pdev has already been initialized by
device_initialize(), but the failure path only reports the error and
returns without dropping the device reference for the current platform
device:
sm501_register_device()
-> platform_device_register(pdev)
-> device_initialize(&pdev->dev)
-> setup_pdev_dma_masks(pdev)
-> platform_device_add(pdev)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review. |
