| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix connections leak when tlink setup failed
If the tlink setup failed, lost to put the connections, then
the module refcnt leak since the cifsd kthread not exit.
Also leak the fscache info, and for next mount with fsc, it will
print the follow errors:
CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)
Let's check the result of tlink setup, and do some cleanup. |
| In the Linux kernel, the following vulnerability has been resolved:
hugetlbfs: don't delete error page from pagecache
This change is very similar to the change that was made for shmem [1], and
it solves the same problem but for HugeTLBFS instead.
Currently, when poison is found in a HugeTLB page, the page is removed
from the page cache. That means that attempting to map or read that
hugepage in the future will result in a new hugepage being allocated
instead of notifying the user that the page was poisoned. As [1] states,
this is effectively memory corruption.
The fix is to leave the page in the page cache. If the user attempts to
use a poisoned HugeTLB page with a syscall, the syscall will fail with
EIO, the same error code that shmem uses. For attempts to map the page,
the thread will get a BUS_MCEERR_AR SIGBUS.
[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens") |
| A vulnerability classified as problematic was found in chaitak-gorai Blogbook up to 92f5cf90f8a7e6566b576fe0952e14e1c6736513. This vulnerability affects unknown code of the file /search.php of the component GET Parameter Handler. The manipulation of the argument Search leads to denial of service. The exploit has been disclosed to the public and may be used. This product is using a rolling release to provide continious delivery. Therefore, no version details for affected nor updated releases are available. The vendor was contacted early about this disclosure but did not respond in any way. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/drv: Fix potential memory leak in drm_dev_init()
drm_dev_init() will add drm_dev_init_release() as a callback. When
drmm_add_action() failed, the release function won't be added. As the
result, the ref cnt added by device_get() in drm_dev_init() won't be put
by drm_dev_init_release(), which leads to the memleak. Use
drmm_add_action_or_reset() instead of drmm_add_action() to prevent
memleak.
unreferenced object 0xffff88810bc0c800 (size 2048):
comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s)
hex dump (first 32 bytes):
e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................
20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<.............
backtrace:
[<000000007251f72d>] __kmalloc+0x4b/0x1c0
[<0000000045f21f26>] platform_device_alloc+0x2d/0xe0
[<000000004452a479>] platform_device_register_full+0x24/0x1c0
[<0000000089f4ea61>] 0xffffffffa0736051
[<00000000235b2441>] do_one_initcall+0x7a/0x380
[<0000000001a4a177>] do_init_module+0x5c/0x230
[<000000002bf8a8e2>] load_module+0x227d/0x2420
[<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140
[<00000000c99fc324>] do_syscall_64+0x3f/0x90
[<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
| A vulnerability was found in the Infinispan component in Red Hat Data Grid. The REST compare API may have a buffer leak and an out of memory error can occur when sending continual requests with large POST data to the REST API. |
| An issue was discovered in 5.1 before 5.1.14, 4.2 before 4.2.26, and 5.2 before 5.2.8.
NFKC normalization in Python is slow on Windows. As a consequence, `django.http.HttpResponseRedirect`, `django.http.HttpResponsePermanentRedirect`, and the shortcut `django.shortcuts.redirect` were subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.
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:
scsi: mpi3mr: Fix memory leaks in mpi3mr_init_ioc()
Don't allocate memory again when IOC is being reinitialized. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix config page DMA memory leak
A fix for:
DMA-API: pci 0000:83:00.0: device driver has pending DMA allocations while released from device [count=1] |
| In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc75xx: Limit packet length to skb->len
Packet length retrieved from skb data may be larger than
the actual socket buffer length (up to 9026 bytes). In such
case the cloned skb passed up the network stack will leak
kernel memory contents. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix sas_hba.phy memory leak in mpi3mr_remove()
Free mrioc->sas_hba.phy at .remove. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix expander node leak in mpi3mr_remove()
Add a missing resource clean up in .remove. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix throttle_groups memory leak
Add a missing kfree(). |
| In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a server shutdown leak
Fix a race where kthread_stop() may prevent the threadfn from ever getting
called. If that happens the svc_rqst will not be cleaned up. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: mpi3mr: Fix mpi3mr_hba_port memory leak in mpi3mr_remove()
Free mpi3mr_hba_port at .remove. |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Remove the /proc/scsi/${proc_name} directory earlier
Remove the /proc/scsi/${proc_name} directory earlier to fix a race
condition between unloading and reloading kernel modules. This fixes a bug
introduced in 2009 by commit 77c019768f06 ("[SCSI] fix /proc memory leak in
the SCSI core").
Fix the following kernel warning:
proc_dir_entry 'scsi/scsi_debug' already registered
WARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0
Call Trace:
proc_mkdir+0xb5/0xe0
scsi_proc_hostdir_add+0xb5/0x170
scsi_host_alloc+0x683/0x6c0
sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]
really_probe+0x159/0x540
__driver_probe_device+0xdc/0x230
driver_probe_device+0x4f/0x120
__device_attach_driver+0xef/0x180
bus_for_each_drv+0xe5/0x130
__device_attach+0x127/0x290
device_initial_probe+0x17/0x20
bus_probe_device+0x110/0x130
device_add+0x673/0xc80
device_register+0x1e/0x30
sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]
scsi_debug_init+0x64f/0x1000 [scsi_debug]
do_one_initcall+0xd7/0x470
do_init_module+0xe7/0x330
load_module+0x122a/0x12c0
__do_sys_finit_module+0x124/0x1a0
__x64_sys_finit_module+0x46/0x50
do_syscall_64+0x38/0x80
entry_SYSCALL_64_after_hwframe+0x46/0xb0 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix kmemleak warning for percpu hashmap
Vlad Poenaru reported the following kmemleak issue:
unreferenced object 0x606fd7c44ac8 (size 32):
backtrace (crc 0):
pcpu_alloc_noprof+0x730/0xeb0
bpf_map_alloc_percpu+0x69/0xc0
prealloc_init+0x9d/0x1b0
htab_map_alloc+0x363/0x510
map_create+0x215/0x3a0
__sys_bpf+0x16b/0x3e0
__x64_sys_bpf+0x18/0x20
do_syscall_64+0x7b/0x150
entry_SYSCALL_64_after_hwframe+0x4b/0x53
Further investigation shows the reason is due to not 8-byte aligned
store of percpu pointer in htab_elem_set_ptr():
*(void __percpu **)(l->key + key_size) = pptr;
Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size
is 4, that means pptr is stored in a location which is 4 byte aligned but
not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based
on 8 byte stride, so it won't detect above pptr, hence reporting the memory
leak.
In htab_map_alloc(), we already have
htab->elem_size = sizeof(struct htab_elem) +
round_up(htab->map.key_size, 8);
if (percpu)
htab->elem_size += sizeof(void *);
else
htab->elem_size += round_up(htab->map.value_size, 8);
So storing pptr with 8-byte alignment won't cause any problem and can fix
kmemleak too.
The issue can be reproduced with bpf selftest as well:
1. Enable CONFIG_DEBUG_KMEMLEAK config
2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.
The purpose is to keep map available so kmemleak can be detected.
3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported. |
| 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. |
| LibreChat version 0.7.9 is vulnerable to a Denial of Service (DoS) attack due to unbounded parameter values in the `/api/memories` endpoint. The `key` and `value` parameters accept arbitrarily large inputs without proper validation, leading to a null pointer error in the Rust-based backend when excessively large values are submitted. This results in the inability to create new memories, impacting the stability of the service. |
| The etcd package distributed with the Red Hat OpenStack platform has an incomplete fix for CVE-2022-41723. This issue occurs because the etcd package in the Red Hat OpenStack platform is using http://golang.org/x/net/http2 instead of the one provided by Red Hat Enterprise Linux versions, meaning it should be updated at compile time instead. |
| Uncontrolled resource consumption in Windows Remote Desktop Services allows an unauthorized attacker to deny service over a network. |
