| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
coresight: Fix memory leak in acpi_buffer->pointer
There are memory leaks reported by kmemleak:
...
unreferenced object 0xffff00213c141000 (size 1024):
comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s)
hex dump (first 32 bytes):
04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........<!...
00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00 ................
backtrace:
[<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348
[<00000000b0fc7ceb>] __kmalloc+0x58/0x108
[<0000000064ff4695>] acpi_os_allocate+0x2c/0x68
[<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0
[<0000000024583908>] acpi_evaluate_object+0x388/0x438
[<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240
[<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight]
...
The ACPI buffer memory (buf.pointer) should be freed. But the buffer
is also used after returning from acpi_get_dsd_graph().
Move the temporary variables buf to acpi_coresight_parse_graph(),
and free it before the function return to prevent memory leak. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix scheduling while atomic in decompression path
[ 16.945668][ C0] Call trace:
[ 16.945678][ C0] dump_backtrace+0x110/0x204
[ 16.945706][ C0] dump_stack_lvl+0x84/0xbc
[ 16.945735][ C0] __schedule_bug+0xb8/0x1ac
[ 16.945756][ C0] __schedule+0x724/0xbdc
[ 16.945778][ C0] schedule+0x154/0x258
[ 16.945793][ C0] bit_wait_io+0x48/0xa4
[ 16.945808][ C0] out_of_line_wait_on_bit+0x114/0x198
[ 16.945824][ C0] __sync_dirty_buffer+0x1f8/0x2e8
[ 16.945853][ C0] __f2fs_commit_super+0x140/0x1f4
[ 16.945881][ C0] f2fs_commit_super+0x110/0x28c
[ 16.945898][ C0] f2fs_handle_error+0x1f4/0x2f4
[ 16.945917][ C0] f2fs_decompress_cluster+0xc4/0x450
[ 16.945942][ C0] f2fs_end_read_compressed_page+0xc0/0xfc
[ 16.945959][ C0] f2fs_handle_step_decompress+0x118/0x1cc
[ 16.945978][ C0] f2fs_read_end_io+0x168/0x2b0
[ 16.945993][ C0] bio_endio+0x25c/0x2c8
[ 16.946015][ C0] dm_io_dec_pending+0x3e8/0x57c
[ 16.946052][ C0] clone_endio+0x134/0x254
[ 16.946069][ C0] bio_endio+0x25c/0x2c8
[ 16.946084][ C0] blk_update_request+0x1d4/0x478
[ 16.946103][ C0] scsi_end_request+0x38/0x4cc
[ 16.946129][ C0] scsi_io_completion+0x94/0x184
[ 16.946147][ C0] scsi_finish_command+0xe8/0x154
[ 16.946164][ C0] scsi_complete+0x90/0x1d8
[ 16.946181][ C0] blk_done_softirq+0xa4/0x11c
[ 16.946198][ C0] _stext+0x184/0x614
[ 16.946214][ C0] __irq_exit_rcu+0x78/0x144
[ 16.946234][ C0] handle_domain_irq+0xd4/0x154
[ 16.946260][ C0] gic_handle_irq.33881+0x5c/0x27c
[ 16.946281][ C0] call_on_irq_stack+0x40/0x70
[ 16.946298][ C0] do_interrupt_handler+0x48/0xa4
[ 16.946313][ C0] el1_interrupt+0x38/0x68
[ 16.946346][ C0] el1h_64_irq_handler+0x20/0x30
[ 16.946362][ C0] el1h_64_irq+0x78/0x7c
[ 16.946377][ C0] finish_task_switch+0xc8/0x3d8
[ 16.946394][ C0] __schedule+0x600/0xbdc
[ 16.946408][ C0] preempt_schedule_common+0x34/0x5c
[ 16.946423][ C0] preempt_schedule+0x44/0x48
[ 16.946438][ C0] process_one_work+0x30c/0x550
[ 16.946456][ C0] worker_thread+0x414/0x8bc
[ 16.946472][ C0] kthread+0x16c/0x1e0
[ 16.946486][ C0] ret_from_fork+0x10/0x20 |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.2 before 18.4.5, 18.5 before 18.5.3, and 18.6 before 18.6.1 that could have allowed an authenticated user with access to certain logs to obtain sensitive tokens under specific conditions. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/disp: fix use-after-free in error handling of nouveau_connector_create
We can't simply free the connector after calling drm_connector_init on it.
We need to clean up the drm side first.
It might not fix all regressions from commit 2b5d1c29f6c4
("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts"),
but at least it fixes a memory corruption in error handling related to
that commit. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: imx: clk-imxrt1050: fix memory leak in imxrt1050_clocks_probe
Use devm_of_iomap() instead of of_iomap() to automatically
handle the unused ioremap region. If any error occurs, regions allocated by
kzalloc() will leak, but using devm_kzalloc() instead will automatically
free the memory using devm_kfree().
Also, fix error handling of hws by adding unregister_hws label, which
unregisters remaining hws when iomap failed. |
| In the Linux kernel, the following vulnerability has been resolved:
ubi: ensure that VID header offset + VID header size <= alloc, size
Ensure that the VID header offset + VID header size does not exceed
the allocated area to avoid slab OOB.
BUG: KASAN: slab-out-of-bounds in crc32_body lib/crc32.c:111 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_generic lib/crc32.c:179 [inline]
BUG: KASAN: slab-out-of-bounds in crc32_le_base+0x58c/0x626 lib/crc32.c:197
Read of size 4 at addr ffff88802bb36f00 by task syz-executor136/1555
CPU: 2 PID: 1555 Comm: syz-executor136 Tainted: G W
6.0.0-1868 #1
Hardware name: Red Hat KVM, BIOS 1.13.0-2.module+el8.3.0+7860+a7792d29
04/01/2014
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0x85/0xad lib/dump_stack.c:106
print_address_description mm/kasan/report.c:317 [inline]
print_report.cold.13+0xb6/0x6bb mm/kasan/report.c:433
kasan_report+0xa7/0x11b mm/kasan/report.c:495
crc32_body lib/crc32.c:111 [inline]
crc32_le_generic lib/crc32.c:179 [inline]
crc32_le_base+0x58c/0x626 lib/crc32.c:197
ubi_io_write_vid_hdr+0x1b7/0x472 drivers/mtd/ubi/io.c:1067
create_vtbl+0x4d5/0x9c4 drivers/mtd/ubi/vtbl.c:317
create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0x0
RIP: 0033:0x7f96d5cf753d
Code:
RSP: 002b:00007fffd72206f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f96d5cf753d
RDX: 0000000020000080 RSI: 0000000040186f40 RDI: 0000000000000003
RBP: 0000000000400cd0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000400be0
R13: 00007fffd72207e0 R14: 0000000000000000 R15: 0000000000000000
</TASK>
Allocated by task 1555:
kasan_save_stack+0x20/0x3d mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:45 [inline]
set_alloc_info mm/kasan/common.c:437 [inline]
____kasan_kmalloc mm/kasan/common.c:516 [inline]
__kasan_kmalloc+0x88/0xa3 mm/kasan/common.c:525
kasan_kmalloc include/linux/kasan.h:234 [inline]
__kmalloc+0x138/0x257 mm/slub.c:4429
kmalloc include/linux/slab.h:605 [inline]
ubi_alloc_vid_buf drivers/mtd/ubi/ubi.h:1093 [inline]
create_vtbl+0xcc/0x9c4 drivers/mtd/ubi/vtbl.c:295
create_empty_lvol drivers/mtd/ubi/vtbl.c:500 [inline]
ubi_read_volume_table+0x67b/0x288a drivers/mtd/ubi/vtbl.c:812
ubi_attach+0xf34/0x1603 drivers/mtd/ubi/attach.c:1601
ubi_attach_mtd_dev+0x6f3/0x185e drivers/mtd/ubi/build.c:965
ctrl_cdev_ioctl+0x2db/0x347 drivers/mtd/ubi/cdev.c:1043
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl fs/ioctl.c:856 [inline]
__x64_sys_ioctl+0x193/0x213 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3e/0x86 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0x0
The buggy address belongs to the object at ffff88802bb36e00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
256-byte region [ffff88802bb36e00, ffff88802bb36f00)
The buggy address belongs to the physical page:
page:00000000ea4d1263 refcount:1 mapcount:0 mapping:0000000000000000
index:0x0 pfn:0x2bb36
head:00000000ea4d1263 order:1 compound_mapcount:0 compound_pincount:0
flags: 0xfffffc0010200(slab|head|node=0|zone=1|lastcpupid=0x1fffff)
raw: 000fffffc0010200 ffffea000066c300 dead000000000003 ffff888100042b40
raw: 0000000000000000 00000000001
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
arm64: acpi: Fix possible memory leak of ffh_ctxt
Allocated 'ffh_ctxt' memory leak is possible if the SMCCC version
and conduit checks fail and -EOPNOTSUPP is returned without freeing the
allocated memory.
Fix the same by moving the allocation after the SMCCC version and
conduit checks. |
| A crafted NTFS image can cause heap exhaustion in ntfs_get_attribute_value in NTFS-3G through 2021.8.22. |
| Open Forms allows users create and publish smart forms. Prior to versions 3.2.7 and 3.3.3, forms where the prefill data fields are dynamically set to readonly/disabled can be modified by malicious users deliberately trying to modify data they're not supposed to. For regular users, the form fields are marked as readonly and cannot be modified through the user interface. This issue has been patched in versions 3.2.7 and 3.3.3. |
| Early versions of Operator-SDK provided an insecure method to allow operator containers to run in environments that used a random UID. Operator-SDK before 0.15.2 provided a script, user_setup, which modifies the permissions of the /etc/passwd file to 664 during build time. Developers who used Operator-SDK before 0.15.2 to scaffold their operator may still be impacted by this if the insecure user_setup script is still being used to build new container images.
In affected images, the /etc/passwd file is created during build time with group-writable permissions and a group ownership of root (gid=0). An attacker who can execute commands within an affected container, even as a non-root user, may be able to leverage their membership in the root group to modify the /etc/passwd file. This could allow the attacker to add a new user with any arbitrary UID, including UID 0, leading to full root privileges within the container. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.3 before 18.4.5, 18.5 before 18.5.3, and 18.6 before 18.6.1 that under specific conditions could have allowed an unauthenticated user to join arbitrary organizations by changing headers on some requests. |
| A crafted NTFS image can cause a heap-based buffer overflow in ntfs_names_full_collate in NTFS-3G through 2021.8.22. |
| A crafted NTFS image can cause a heap-based buffer overflow in ntfs_mft_rec_alloc in NTFS-3G through 2021.8.22. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.10 before 18.4.5, 18.5 before 18.5.3, and 18.6 before 18.6.1 that could have allowed an unauthenticated user to cause a Denial of Service condition by sending specifically crafted requests containing malicious JSON payloads. |
| Insertion of Sensitive Information into Log File vulnerability in upKeeper Solutions upKeeper Manager allows Use of Known Domain Credentials.This issue affects upKeeper Manager: from 5.2.0 before 5.2.12. |
| A crafted NTFS image can cause a heap-based buffer overflow in ntfs_check_log_client_array in NTFS-3G through 2021.8.22. |
| Improper neutralisation of format characters in the settings of Revive Adserver 5.5.2 and 6.0.1 and earlier versions causes an administrator user to disable the admin user console due to a fatal PHP error. |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.7 to 18.2.8, 18.3 before 18.3.4, and 18.4 before 18.4.2 that could have allowed authenticated users without project membership to view sensitive manual CI/CD variables by querying the GraphQL API. |
| A flaw was found in the c-ares package. The ares_set_sortlist is missing checks about the validity of the input string, which allows a possible arbitrary length stack overflow. This issue may cause a denial of service or a limited impact on confidentiality and integrity. |
| Missing JSON Content-Type header in a script in Revive Adserver 6.0.1 and 5.5.2 and earlier versions causes a stored XSS attack to be possible for a logged in manager user. |
