| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
binder: fix use-after-free in binderfs_evict_inode()
Running 'stress-ng --binderfs 16 --timeout 300' under KASAN-enabled
kernel, I've noticed the following:
BUG: KASAN: slab-use-after-free in binderfs_evict_inode+0x1de/0x2d0
Write of size 8 at addr ffff88807379bc08 by task stress-ng-binde/1699
CPU: 0 UID: 0 PID: 1699 Comm: stress-ng-binde Not tainted 6.14.0-rc7-g586de92313fc-dirty #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x1c2/0x2a0
? __pfx_dump_stack_lvl+0x10/0x10
? __pfx__printk+0x10/0x10
? __pfx_lock_release+0x10/0x10
? __virt_addr_valid+0x18c/0x540
? __virt_addr_valid+0x469/0x540
print_report+0x155/0x840
? __virt_addr_valid+0x18c/0x540
? __virt_addr_valid+0x469/0x540
? __phys_addr+0xba/0x170
? binderfs_evict_inode+0x1de/0x2d0
kasan_report+0x147/0x180
? binderfs_evict_inode+0x1de/0x2d0
binderfs_evict_inode+0x1de/0x2d0
? __pfx_binderfs_evict_inode+0x10/0x10
evict+0x524/0x9f0
? __pfx_lock_release+0x10/0x10
? __pfx_evict+0x10/0x10
? do_raw_spin_unlock+0x4d/0x210
? _raw_spin_unlock+0x28/0x50
? iput+0x697/0x9b0
__dentry_kill+0x209/0x660
? shrink_kill+0x8d/0x2c0
shrink_kill+0xa9/0x2c0
shrink_dentry_list+0x2e0/0x5e0
shrink_dcache_parent+0xa2/0x2c0
? __pfx_shrink_dcache_parent+0x10/0x10
? __pfx_lock_release+0x10/0x10
? __pfx_do_raw_spin_lock+0x10/0x10
do_one_tree+0x23/0xe0
shrink_dcache_for_umount+0xa0/0x170
generic_shutdown_super+0x67/0x390
kill_litter_super+0x76/0xb0
binderfs_kill_super+0x44/0x90
deactivate_locked_super+0xb9/0x130
cleanup_mnt+0x422/0x4c0
? lockdep_hardirqs_on+0x9d/0x150
task_work_run+0x1d2/0x260
? __pfx_task_work_run+0x10/0x10
resume_user_mode_work+0x52/0x60
syscall_exit_to_user_mode+0x9a/0x120
do_syscall_64+0x103/0x210
? asm_sysvec_apic_timer_interrupt+0x1a/0x20
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0xcac57b
Code: c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 31 f6 e9 05 00 00 00 0f 1f 44 00 00 f3 0f 1e fa b8
RSP: 002b:00007ffecf4226a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6
RAX: 0000000000000000 RBX: 00007ffecf422720 RCX: 0000000000cac57b
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007ffecf422850
RBP: 00007ffecf422850 R08: 0000000028d06ab1 R09: 7fffffffffffffff
R10: 3fffffffffffffff R11: 0000000000000246 R12: 00007ffecf422718
R13: 00007ffecf422710 R14: 00007f478f87b658 R15: 00007ffecf422830
</TASK>
Allocated by task 1705:
kasan_save_track+0x3e/0x80
__kasan_kmalloc+0x8f/0xa0
__kmalloc_cache_noprof+0x213/0x3e0
binderfs_binder_device_create+0x183/0xa80
binder_ctl_ioctl+0x138/0x190
__x64_sys_ioctl+0x120/0x1b0
do_syscall_64+0xf6/0x210
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 1705:
kasan_save_track+0x3e/0x80
kasan_save_free_info+0x46/0x50
__kasan_slab_free+0x62/0x70
kfree+0x194/0x440
evict+0x524/0x9f0
do_unlinkat+0x390/0x5b0
__x64_sys_unlink+0x47/0x50
do_syscall_64+0xf6/0x210
entry_SYSCALL_64_after_hwframe+0x77/0x7f
This 'stress-ng' workload causes the concurrent deletions from
'binder_devices' and so requires full-featured synchronization
to prevent list corruption.
I've found this issue independently but pretty sure that syzbot did
the same, so Reported-by: and Closes: should be applicable here as well. |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix max_sge overflow in smb_extract_folioq_to_rdma()
This fixes the following problem:
[ 749.901015] [ T8673] run fstests cifs/001 at 2025-06-17 09:40:30
[ 750.346409] [ T9870] ==================================================================
[ 750.346814] [ T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.347330] [ T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870
[ 750.347705] [ T9870]
[ 750.348077] [ T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)
[ 750.348082] [ T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 750.348085] [ T9870] Call Trace:
[ 750.348086] [ T9870] <TASK>
[ 750.348088] [ T9870] dump_stack_lvl+0x76/0xa0
[ 750.348106] [ T9870] print_report+0xd1/0x640
[ 750.348116] [ T9870] ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 750.348120] [ T9870] ? kasan_complete_mode_report_info+0x26/0x210
[ 750.348124] [ T9870] kasan_report+0xe7/0x130
[ 750.348128] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348262] [ T9870] ? smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348377] [ T9870] __asan_report_store8_noabort+0x17/0x30
[ 750.348381] [ T9870] smb_set_sge+0x2cc/0x3b0 [cifs]
[ 750.348496] [ T9870] smbd_post_send_iter+0x1990/0x3070 [cifs]
[ 750.348625] [ T9870] ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]
[ 750.348741] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.348749] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.348870] [ T9870] ? cifs_flush+0x153/0x320 [cifs]
[ 750.348990] [ T9870] ? update_stack_state+0x2a0/0x670
[ 750.348995] [ T9870] smbd_send+0x58c/0x9c0 [cifs]
[ 750.349117] [ T9870] ? __pfx_smbd_send+0x10/0x10 [cifs]
[ 750.349231] [ T9870] ? unwind_get_return_address+0x65/0xb0
[ 750.349235] [ T9870] ? __pfx_stack_trace_consume_entry+0x10/0x10
[ 750.349242] [ T9870] ? arch_stack_walk+0xa7/0x100
[ 750.349250] [ T9870] ? stack_trace_save+0x92/0xd0
[ 750.349254] [ T9870] __smb_send_rqst+0x931/0xec0 [cifs]
[ 750.349374] [ T9870] ? kernel_text_address+0x173/0x190
[ 750.349379] [ T9870] ? kasan_save_stack+0x39/0x70
[ 750.349382] [ T9870] ? kasan_save_track+0x18/0x70
[ 750.349385] [ T9870] ? __kasan_slab_alloc+0x9d/0xa0
[ 750.349389] [ T9870] ? __pfx___smb_send_rqst+0x10/0x10 [cifs]
[ 750.349508] [ T9870] ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]
[ 750.349626] [ T9870] ? cifs_call_async+0x277/0xb00 [cifs]
[ 750.349746] [ T9870] ? cifs_issue_write+0x256/0x610 [cifs]
[ 750.349867] [ T9870] ? netfs_do_issue_write+0xc2/0x340 [netfs]
[ 750.349900] [ T9870] ? netfs_advance_write+0x45b/0x1270 [netfs]
[ 750.349929] [ T9870] ? netfs_write_folio+0xd6c/0x1be0 [netfs]
[ 750.349958] [ T9870] ? netfs_writepages+0x2e9/0xa80 [netfs]
[ 750.349987] [ T9870] ? do_writepages+0x21f/0x590
[ 750.349993] [ T9870] ? filemap_fdatawrite_wbc+0xe1/0x140
[ 750.349997] [ T9870] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 750.350002] [ T9870] smb_send_rqst+0x22e/0x2f0 [cifs]
[ 750.350131] [ T9870] ? __pfx_smb_send_rqst+0x10/0x10 [cifs]
[ 750.350255] [ T9870] ? local_clock_noinstr+0xe/0xd0
[ 750.350261] [ T9870] ? kasan_save_alloc_info+0x37/0x60
[ 750.350268] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.350271] [ T9870] ? _raw_spin_lock+0x81/0xf0
[ 750.350275] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.350278] [ T9870] ? smb2_setup_async_request+0x293/0x580 [cifs]
[ 750.350398] [ T9870] cifs_call_async+0x477/0xb00 [cifs]
[ 750.350518] [ T9870] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[ 750.350636] [ T9870] ? __pfx_cifs_call_async+0x10/0x10 [cifs]
[ 750.350756] [ T9870] ? __pfx__raw_spin_lock+0x10/0x10
[ 750.350760] [ T9870] ? __kasan_check_write+0x14/0x30
[ 750.350763] [ T98
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()
The RPC container is released after being passed to r535_gsp_rpc_send().
When sending the initial fragment of a large RPC and passing the
caller's RPC container, the container will be freed prematurely. Subsequent
attempts to send remaining fragments will therefore result in a
use-after-free.
Allocate a temporary RPC container for holding the initial fragment of a
large RPC when sending. Free the caller's container when all fragments
are successfully sent.
[ Rebase onto Blackwell changes. - Danilo ] |
| Insufficient input sanitization in the dashboard label or path can allow
an attacker to trigger a device error causing information disclosure or
data manipulation. |
| Due to insufficient sanitization, an attacker can upload a specially
crafted configuration file to traverse directories and achieve remote
code execution with system-level permissions. |
| Due to insufficient sanitization, an attacker can upload a specially
crafted configuration file to traverse directories and achieve remote
code execution with system-level permissions. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86/amd: pmf: Use device managed allocations
If setting up smart PC fails for any reason then this can lead to
a double free when unloading amd-pmf. This is because dev->buf was
freed but never set to NULL and is again freed in amd_pmf_remove().
To avoid subtle allocation bugs in failures leading to a double free
change all allocations into device managed allocations. |
| A vulnerability in Absolute Persistence® versions before 2.8 exists when it is not activated. This may allow a skilled attacker with both physical access to the device, and full hostile network control, to initiate OS commands on the device. To remediate this vulnerability, update the device firmware to the latest available version. Please contact the device manufacturer for upgrade instructions or contact Absolute Security, see reference below. |
| In the Linux kernel, the following vulnerability has been resolved:
iio: backend: fix out-of-bound write
The buffer is set to 80 character. If a caller write more characters,
count is truncated to the max available space in "simple_write_to_buffer".
But afterwards a string terminator is written to the buffer at offset count
without boundary check. The zero termination is written OUT-OF-BOUND.
Add a check that the given buffer is smaller then the buffer to prevent. |
| IBM Db2 10.5.0 through 10.5.11, 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) is vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query. |
| IBM Db2 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) is vulnerable to a denial of service as the server may crash under certain conditions with a specially crafted query. |
| IBM Db2 10.5.0 through 10.5.11, 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux could allow an authenticated user to regain access after account lockout due to password use after expiration date. |
| IBM Db2 10.5.0 through 10.5.11, 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) could allow an authenticated user to cause a denial due to the improper release of resources after use. |
| IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) could allow an authenticated user to cause a denial of service due to improper allocation of resources. |
| IBM Db2 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes Db2 Connect Server) clpplus command exposes user credentials to the terminal which could be obtained by a third party with physical access to the system. |
| IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux, UNIX and Windows (includes DB2 Connect Server) could allow a local user to cause a denial of service due to the database monitor script incorrectly detecting that the instance is still starting under specific conditions. |
| A vulnerability in the RADIUS setting Reject RADIUS requests from clients with repeated failures on Cisco Identity Services Engine (ISE) could allow an unauthenticated, remote attacker to cause Cisco ISE to restart unexpectedly.
This vulnerability is due to a logic error when processing a RADIUS access request for a MAC address that is already a rejected endpoint. An attacker could exploit this vulnerability by sending a specific sequence of multiple crafted RADIUS access request messages to Cisco ISE. A successful exploit could allow the attacker to cause a denial of service (DoS) condition when Cisco ISE restarts. |
| In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: arkfb: Check the size of screen before memset_io()
In the function arkfb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 659.399066] BUG: unable to handle page fault for address: ffffc90003000000
[ 659.399077] #PF: supervisor write access in kernel mode
[ 659.399079] #PF: error_code(0x0002) - not-present page
[ 659.399094] RIP: 0010:memset_orig+0x33/0xb0
[ 659.399116] Call Trace:
[ 659.399122] arkfb_set_par+0x143f/0x24c0
[ 659.399130] fb_set_var+0x604/0xeb0
[ 659.399161] do_fb_ioctl+0x234/0x670
[ 659.399189] fb_ioctl+0xdd/0x130
Fix the this by checking the value of 'screen_size' before memset_io(). |
| In the Linux kernel, the following vulnerability has been resolved:
video: fbdev: vt8623fb: Check the size of screen before memset_io()
In the function vt8623fb_set_par(), the value of 'screen_size' is
calculated by the user input. If the user provides the improper value,
the value of 'screen_size' may larger than 'info->screen_size', which
may cause the following bug:
[ 583.339036] BUG: unable to handle page fault for address: ffffc90005000000
[ 583.339049] #PF: supervisor write access in kernel mode
[ 583.339052] #PF: error_code(0x0002) - not-present page
[ 583.339074] RIP: 0010:memset_orig+0x33/0xb0
[ 583.339110] Call Trace:
[ 583.339118] vt8623fb_set_par+0x11cd/0x21e0
[ 583.339146] fb_set_var+0x604/0xeb0
[ 583.339181] do_fb_ioctl+0x234/0x670
[ 583.339209] fb_ioctl+0xdd/0x130
Fix the this by checking the value of 'screen_size' before memset_io(). |
| In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: do not allow CHAIN_ID to refer to another table
When doing lookups for chains on the same batch by using its ID, a chain
from a different table can be used. If a rule is added to a table but
refers to a chain in a different table, it will be linked to the chain in
table2, but would have expressions referring to objects in table1.
Then, when table1 is removed, the rule will not be removed as its linked to
a chain in table2. When expressions in the rule are processed or removed,
that will lead to a use-after-free.
When looking for chains by ID, use the table that was used for the lookup
by name, and only return chains belonging to that same table. |
