| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| An issue in KiloView Dual Channel 4k HDMI & 3G-SDI HEVC Video Encoder Firmware v.1.20.0006 allows a remote attacker to cause a denial of service via the systemctrl API System/reFactory component. |
| In the Linux kernel, the following vulnerability has been resolved:
blk-iolatency: Fix memory leak on add_disk() failures
When a gendisk is successfully initialized but add_disk() fails such as when
a loop device has invalid number of minor device numbers specified,
blkcg_init_disk() is called during init and then blkcg_exit_disk() during
error handling. Unfortunately, iolatency gets initialized in the former but
doesn't get cleaned up in the latter.
This is because, in non-error cases, the cleanup is performed by
del_gendisk() calling rq_qos_exit(), the assumption being that rq_qos
policies, iolatency being one of them, can only be activated once the disk
is fully registered and visible. That assumption is true for wbt and iocost,
but not so for iolatency as it gets initialized before add_disk() is called.
It is desirable to lazy-init rq_qos policies because they are optional
features and add to hot path overhead once initialized - each IO has to walk
all the registered rq_qos policies. So, we want to switch iolatency to lazy
init too. However, that's a bigger change. As a fix for the immediate
problem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk().
This is safe because duplicate calls to rq_qos_exit() become noop's. |
| In the Linux kernel, the following vulnerability has been resolved:
media: i2c: hi846: Fix memory leak in hi846_parse_dt()
If any of the checks related to the supported link frequencies fail, then
the V4L2 fwnode resources don't get released before returning, which leads
to a memleak. Fix this by properly freeing the V4L2 fwnode data in a
designated label. |
| In the Linux kernel, the following vulnerability has been resolved:
media: solo6x10: fix possible memory leak in solo_sysfs_init()
If device_register() returns error in solo_sysfs_init(), the
name allocated by dev_set_name() need be freed. As comment of
device_register() says, it should use put_device() to give up
the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
r6040: Fix kmemleak in probe and remove
There is a memory leaks reported by kmemleak:
unreferenced object 0xffff888116111000 (size 2048):
comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)
hex dump (first 32 bytes):
00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................
08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff815bcd82>] kmalloc_trace+0x22/0x60
[<ffffffff827e20ee>] phy_device_create+0x4e/0x90
[<ffffffff827e6072>] get_phy_device+0xd2/0x220
[<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0
[<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0
[<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040]
...
The problem occurs in probe process as follows:
r6040_init_one:
mdiobus_register
mdiobus_scan <- alloc and register phy_device,
the reference count of phy_device is 3
r6040_mii_probe
phy_connect <- connect to the first phy_device,
so the reference count of the first
phy_device is 4, others are 3
register_netdev <- fault inject succeeded, goto error handling path
// error handling path
err_out_mdio_unregister:
mdiobus_unregister(lp->mii_bus);
err_out_mdio:
mdiobus_free(lp->mii_bus); <- the reference count of the first
phy_device is 1, it is not released
and other phy_devices are released
// similarly, the remove process also has the same problem
The root cause is traced to the phy_device is not disconnected when
removes one r6040 device in r6040_remove_one() or on error handling path
after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet
device is connected to the first PHY device of mii_bus, in order to
notify the connected driver when the link status changes, which is the
default behavior of the PHY infrastructure to handle everything.
Therefore the phy_device should be disconnected when removes one r6040
device or on error handling path.
Fix it by adding phy_disconnect() when removes one r6040 device or on
error handling path after r6040_mii probed successfully. |
| If the value passed to os.path.expandvars() is user-controlled a
performance degradation is possible when expanding environment
variables. |
| In the Linux kernel, the following vulnerability has been resolved:
firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()
In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will
not be freed through rpi_firmware_delete(), fix this leak by calling
kfree() in the error path. |
| In the Linux kernel, the following vulnerability has been resolved:
usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()
xhci_alloc_stream_info() allocates stream context array for stream_info
->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,
stream_info->stream_ctx_array is not released, which will lead to a
memory leak.
We can fix it by releasing the stream_info->stream_ctx_array with
xhci_free_stream_ctx() on the error path to avoid the potential memory
leak. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue()
If construction of the array of work queues to handle hpd_rx_irq offload
work fails, we need to unwind. Destroy all the created workqueues and
the allocated memory for the hpd_rx_irq_offload_work_queue struct array. |
| An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.
`ASGIRequest` allows a remote attacker to cause a potential denial-of-service via a crafted request with multiple duplicate headers.
Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Jiyong Yang for reporting this issue. |
| An issue was discovered in 6.0 before 6.0.2, 5.2 before 5.2.11, and 4.2 before 4.2.28.
`django.utils.text.Truncator.chars()` and `Truncator.words()` methods (with `html=True`) and the `truncatechars_html` and `truncatewords_html` template filters allow a remote attacker to cause a potential denial-of-service via crafted inputs containing a large number of unmatched HTML end tags.
Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected.
Django would like to thank Seokchan Yoon for reporting this issue. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()
The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()
is not freed after the call, so it leads to memory leak.
The method results in ACPI buffer is not used, so just pass NULL to
wmi_evaluate_method() which fixes the memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: rockchip: Fix memory leak in rockchip_clk_register_pll()
If clk_register() fails, @pll->rate_table may have allocated memory by
kmemdup(), so it needs to be freed, otherwise will cause memory leak
issue, this patch fixes it. |
| In the Linux kernel, the following vulnerability has been resolved:
iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe()
The fsl_pamu_probe() returns directly when create_csd() failed, leaving
irq and memories unreleased.
Fix by jumping to error if create_csd() returns error. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: Fix memory leakage
This patch fixes potential memory leakage and seg fault
in _gpuvm_import_dmabuf() function |
| A vulnerability in danny-avila/librechat allows attackers to exploit the unrestricted Fork Function in `/api/convos/fork` to fork numerous contents rapidly. If the forked content includes a Mermaid graph with a large number of nodes, it can lead to a JavaScript heap out of memory error upon service restart, causing a denial of service. This issue affects the latest version of the product. |
| The `SimpleDirectoryReader` component in `llama_index.core` version 0.12.23 suffers from uncontrolled memory consumption due to a resource management flaw. The vulnerability arises because the user-specified file limit (`num_files_limit`) is applied after all files in a directory are loaded into memory. This can lead to memory exhaustion and degraded performance, particularly in environments with limited resources. The issue is resolved in version 0.12.41. |
| A vulnerability in huggingface/text-generation-inference version 3.3.6 allows unauthenticated remote attackers to exploit unbounded external image fetching during input validation in VLM mode. The issue arises when the router scans inputs for Markdown image links and performs a blocking HTTP GET request, reading the entire response body into memory and cloning it before decoding. This behavior can lead to resource exhaustion, including network bandwidth saturation, memory inflation, and CPU overutilization. The vulnerability is triggered even if the request is later rejected for exceeding token limits. The default deployment configuration, which lacks memory usage limits and authentication, exacerbates the impact, potentially crashing the host machine. The issue is resolved in version 3.3.7. |
| In the Linux kernel, the following vulnerability has been resolved:
media: i2c: ov772x: Fix memleak in ov772x_probe()
A memory leak was reported when testing ov772x with bpf mock device:
AssertionError: unreferenced object 0xffff888109afa7a8 (size 8):
comm "python3", pid 279, jiffies 4294805921 (age 20.681s)
hex dump (first 8 bytes):
80 22 88 15 81 88 ff ff ."......
backtrace:
[<000000009990b438>] __kmalloc_node+0x44/0x1b0
[<000000009e32f7d7>] kvmalloc_node+0x34/0x180
[<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev]
[<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x]
[<000000003f0d225e>] i2c_device_probe+0x28d/0x680
[<00000000e0b6db89>] really_probe+0x17c/0x3f0
[<000000001b19fcee>] __driver_probe_device+0xe3/0x170
[<0000000048370519>] driver_probe_device+0x49/0x120
[<000000005ead07a0>] __device_attach_driver+0xf7/0x150
[<0000000043f452b8>] bus_for_each_drv+0x114/0x180
[<00000000358e5596>] __device_attach+0x1e5/0x2d0
[<0000000043f83c5d>] bus_probe_device+0x126/0x140
[<00000000ee0f3046>] device_add+0x810/0x1130
[<00000000e0278184>] i2c_new_client_device+0x359/0x4f0
[<0000000070baf34f>] of_i2c_register_device+0xf1/0x110
[<00000000a9f2159d>] of_i2c_notify+0x100/0x160
unreferenced object 0xffff888119825c00 (size 256):
comm "python3", pid 279, jiffies 4294805921 (age 20.681s)
hex dump (first 32 bytes):
00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^......
10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\......
backtrace:
[<000000009990b438>] __kmalloc_node+0x44/0x1b0
[<000000009e32f7d7>] kvmalloc_node+0x34/0x180
[<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev]
[<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev]
[<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x]
[<000000003f0d225e>] i2c_device_probe+0x28d/0x680
[<00000000e0b6db89>] really_probe+0x17c/0x3f0
[<000000001b19fcee>] __driver_probe_device+0xe3/0x170
[<0000000048370519>] driver_probe_device+0x49/0x120
[<000000005ead07a0>] __device_attach_driver+0xf7/0x150
[<0000000043f452b8>] bus_for_each_drv+0x114/0x180
[<00000000358e5596>] __device_attach+0x1e5/0x2d0
[<0000000043f83c5d>] bus_probe_device+0x126/0x140
[<00000000ee0f3046>] device_add+0x810/0x1130
[<00000000e0278184>] i2c_new_client_device+0x359/0x4f0
[<0000000070baf34f>] of_i2c_register_device+0xf1/0x110
The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the
error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all
resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()
are leaked. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: hif_usb: fix memory leak of remain_skbs
hif_dev->remain_skb is allocated and used exclusively in
ath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb is
processed and subsequently freed (in error paths) only during the next
call of ath9k_hif_usb_rx_stream().
So, if the urbs are deallocated between those two calls due to the device
deinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()
is not called next time and the allocated remain_skb is leaked. Our local
Syzkaller instance was able to trigger that.
remain_skb makes sense when receiving two consecutive urbs which are
logically linked together, i.e. a specific data field from the first skb
indicates a cached skb to be allocated, memcpy'd with some data and
subsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbs
deallocation supposedly makes that link irrelevant so we need to free the
cached skb in those cases.
Fix the leak by introducing a function to explicitly free remain_skb (if
it is not NULL) when the rx urbs have been deallocated. remain_skb is NULL
when it has not been allocated at all (hif_dev struct is kzalloced) or
when it has been processed in next call to ath9k_hif_usb_rx_stream().
Found by Linux Verification Center (linuxtesting.org) with Syzkaller. |
