| CVE |
Vendors |
Products |
Updated |
CVSS v2 |
CVSS v3 |
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Refuse to evaluate a method if arguments are missing
As reported in [1], a platform firmware update that increased the number
of method parameters and forgot to update a least one of its callers,
caused ACPICA to crash due to use-after-free.
Since this a result of a clear AML issue that arguably cannot be fixed
up by the interpreter (it cannot produce missing data out of thin air),
address it by making ACPICA refuse t ...
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Refuse to evaluate a method if arguments are missing
As reported in [1], a platform firmware update that increased the number
of method parameters and forgot to update a least one of its callers,
caused ACPICA to crash due to use-after-free.
Since this a result of a clear AML issue that arguably cannot be fixed
up by the interpreter (it cannot produce missing data out of thin air),
address it by making ACPICA refuse to evaluate a method if the caller
attempts to pass fewer arguments than expected to it.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect
Remove redundant netif_napi_del() call from disconnect path.
A WARN may be triggered in __netif_napi_del_locked() during USB device
disconnect:
WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
This happens because netif_napi_del() is called in the disconnect path while
NAPI is still enabled. However, it is not necessary ...
In the Linux kernel, the following vulnerability has been resolved:
net: usb: lan78xx: fix WARN in __netif_napi_del_locked on disconnect
Remove redundant netif_napi_del() call from disconnect path.
A WARN may be triggered in __netif_napi_del_locked() during USB device
disconnect:
WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
This happens because netif_napi_del() is called in the disconnect path while
NAPI is still enabled. However, it is not necessary to call netif_napi_del()
explicitly, since unregister_netdev() will handle NAPI teardown automatically
and safely. Removing the redundant call avoids triggering the warning.
Full trace:
lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV
lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV
lan78xx 1-1:1.0 enu1: Link is Down
lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV
------------[ cut here ]------------
WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 __netif_napi_del_locked+0x2b4/0x350
Modules linked in: flexcan can_dev fuse
CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT
Hardware name: SKOV IMX8MP CPU revC - bd500 (DT)
Workqueue: usb_hub_wq hub_event
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : __netif_napi_del_locked+0x2b4/0x350
lr : __netif_napi_del_locked+0x7c/0x350
sp : ffffffc085b673c0
x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8
x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb
x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000
x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000
x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028
x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8
x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000
x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001
x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000
x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000
Call trace:
__netif_napi_del_locked+0x2b4/0x350 (P)
lan78xx_disconnect+0xf4/0x360
usb_unbind_interface+0x158/0x718
device_remove+0x100/0x150
device_release_driver_internal+0x308/0x478
device_release_driver+0x1c/0x30
bus_remove_device+0x1a8/0x368
device_del+0x2e0/0x7b0
usb_disable_device+0x244/0x540
usb_disconnect+0x220/0x758
hub_event+0x105c/0x35e0
process_one_work+0x760/0x17b0
worker_thread+0x768/0xce8
kthread+0x3bc/0x690
ret_from_fork+0x10/0x20
irq event stamp: 211604
hardirqs last enabled at (211603): [<ffffffc0828cc9ec>] _raw_spin_unlock_irqrestore+0x84/0x98
hardirqs last disabled at (211604): [<ffffffc0828a9a84>] el1_dbg+0x24/0x80
softirqs last enabled at (211296): [<ffffffc080095f10>] handle_softirqs+0x820/0xbc8
softirqs last disabled at (210993): [<ffffffc080010288>] __do_softirq+0x18/0x20
---[ end trace 0000000000000000 ]---
lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
mtd: spinand: fix memory leak of ECC engine conf
Memory allocated for the ECC engine conf is not released during spinand
cleanup. Below kmemleak trace is seen for this memory leak:
unreferenced object 0xffffff80064f00e0 (size 8):
comm "swapper/0", pid 1, jiffies 4294937458
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00 ........
backtrace (crc 0):
kmemleak_alloc+0x30/0x40
__kmalloc ...
In the Linux kernel, the following vulnerability has been resolved:
mtd: spinand: fix memory leak of ECC engine conf
Memory allocated for the ECC engine conf is not released during spinand
cleanup. Below kmemleak trace is seen for this memory leak:
unreferenced object 0xffffff80064f00e0 (size 8):
comm "swapper/0", pid 1, jiffies 4294937458
hex dump (first 8 bytes):
00 00 00 00 00 00 00 00 ........
backtrace (crc 0):
kmemleak_alloc+0x30/0x40
__kmalloc_cache_noprof+0x208/0x3c0
spinand_ondie_ecc_init_ctx+0x114/0x200
nand_ecc_init_ctx+0x70/0xa8
nanddev_ecc_engine_init+0xec/0x27c
spinand_probe+0xa2c/0x1620
spi_mem_probe+0x130/0x21c
spi_probe+0xf0/0x170
really_probe+0x17c/0x6e8
__driver_probe_device+0x17c/0x21c
driver_probe_device+0x58/0x180
__device_attach_driver+0x15c/0x1f8
bus_for_each_drv+0xec/0x150
__device_attach+0x188/0x24c
device_initial_probe+0x10/0x20
bus_probe_device+0x11c/0x160
Fix the leak by calling nanddev_ecc_engine_cleanup() inside
spinand_cleanup().
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix iteration of extrefs during log replay
At __inode_add_ref() when processing extrefs, if we jump into the next
label we have an undefined value of victim_name.len, since we haven't
initialized it before we did the goto. This results in an invalid memory
access in the next iteration of the loop since victim_name.len was not
initialized to the length of the name of the current extref.
Fix this by initializing victim_n ...
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix iteration of extrefs during log replay
At __inode_add_ref() when processing extrefs, if we jump into the next
label we have an undefined value of victim_name.len, since we haven't
initialized it before we did the goto. This results in an invalid memory
access in the next iteration of the loop since victim_name.len was not
initialized to the length of the name of the current extref.
Fix this by initializing victim_name.len with the current extref's name
length.
Show More
|
|
In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion
The first kiocb_set_cancel_fn() argument may point at a struct kiocb
that is not embedded inside struct aio_kiocb. With the current code,
depending on the compiler, the req->ki_ctx read happens either before
the IOCB_AIO_RW test or after that test. Move the req->ki_ctx read such
that it is guaranteed that the IOCB_AIO_RW test happens first.
|
|
In the Linux kernel, the following vulnerability has been resolved:
mmc: core: Avoid negative index with array access
Commit 4d0c8d0aef63 ("mmc: core: Use mrq.sbc in close-ended ffu") assigns
prev_idata = idatas[i - 1], but doesn't check that the iterator i is
greater than zero. Let's fix this by adding a check.
|
In the Linux kernel, the following vulnerability has been resolved:
jffs2: check jffs2_prealloc_raw_node_refs() result in few other places
Fuzzing hit another invalid pointer dereference due to the lack of
checking whether jffs2_prealloc_raw_node_refs() completed successfully.
Subsequent logic implies that the node refs have been allocated.
Handle that. The code is ready for propagating the error upwards.
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 5835 ...
In the Linux kernel, the following vulnerability has been resolved:
jffs2: check jffs2_prealloc_raw_node_refs() result in few other places
Fuzzing hit another invalid pointer dereference due to the lack of
checking whether jffs2_prealloc_raw_node_refs() completed successfully.
Subsequent logic implies that the node refs have been allocated.
Handle that. The code is ready for propagating the error upwards.
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 1 PID: 5835 Comm: syz-executor145 Not tainted 5.10.234-syzkaller #0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
RIP: 0010:jffs2_link_node_ref+0xac/0x690 fs/jffs2/nodelist.c:600
Call Trace:
jffs2_mark_erased_block fs/jffs2/erase.c:460 [inline]
jffs2_erase_pending_blocks+0x688/0x1860 fs/jffs2/erase.c:118
jffs2_garbage_collect_pass+0x638/0x1a00 fs/jffs2/gc.c:253
jffs2_reserve_space+0x3f4/0xad0 fs/jffs2/nodemgmt.c:167
jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362
jffs2_write_end+0x712/0x1110 fs/jffs2/file.c:302
generic_perform_write+0x2c2/0x500 mm/filemap.c:3347
__generic_file_write_iter+0x252/0x610 mm/filemap.c:3465
generic_file_write_iter+0xdb/0x230 mm/filemap.c:3497
call_write_iter include/linux/fs.h:2039 [inline]
do_iter_readv_writev+0x46d/0x750 fs/read_write.c:740
do_iter_write+0x18c/0x710 fs/read_write.c:866
vfs_writev+0x1db/0x6a0 fs/read_write.c:939
do_pwritev fs/read_write.c:1036 [inline]
__do_sys_pwritev fs/read_write.c:1083 [inline]
__se_sys_pwritev fs/read_write.c:1078 [inline]
__x64_sys_pwritev+0x235/0x310 fs/read_write.c:1078
do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x67/0xd1
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Prevent attempts to reclaim poisoned pages
TL;DR: SGX page reclaim touches the page to copy its contents to
secondary storage. SGX instructions do not gracefully handle machine
checks. Despite this, the existing SGX code will try to reclaim pages
that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.
The longer story:
Pages used by an enclave only get epc_page->poison set in
arch_memory_failure() ...
In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Prevent attempts to reclaim poisoned pages
TL;DR: SGX page reclaim touches the page to copy its contents to
secondary storage. SGX instructions do not gracefully handle machine
checks. Despite this, the existing SGX code will try to reclaim pages
that it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.
The longer story:
Pages used by an enclave only get epc_page->poison set in
arch_memory_failure() but they currently stay on sgx_active_page_list until
sgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.
epc_page->poison is not checked in the reclaimer logic meaning that, if other
conditions are met, an attempt will be made to reclaim an EPC page that was
poisoned. This is bad because 1. we don't want that page to end up added
to another enclave and 2. it is likely to cause one core to shut down
and the kernel to panic.
Specifically, reclaiming uses microcode operations including "EWB" which
accesses the EPC page contents to encrypt and write them out to non-SGX
memory. Those operations cannot handle MCEs in their accesses other than
by putting the executing core into a special shutdown state (affecting
both threads with HT.) The kernel will subsequently panic on the
remaining cores seeing the core didn't enter MCE handler(s) in time.
Call sgx_unmark_page_reclaimable() to remove the affected EPC page from
sgx_active_page_list on memory error to stop it being considered for
reclaiming.
Testing epc_page->poison in sgx_reclaim_pages() would also work but I assume
it's better to add code in the less likely paths.
The affected EPC page is not added to &node->sgx_poison_page_list until
later in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd.
Membership on other lists doesn't change to avoid changing any of the
lists' semantics except for sgx_active_page_list. There's a "TBD" comment
in arch_memory_failure() about pre-emptive actions, the goal here is not
to address everything that it may imply.
This also doesn't completely close the time window when a memory error
notification will be fatal (for a not previously poisoned EPC page) --
the MCE can happen after sgx_reclaim_pages() has selected its candidates
or even *inside* a microcode operation (actually easy to trigger due to
the amount of time spent in them.)
The spinlock in sgx_unmark_page_reclaimable() is safe because
memory_failure() runs in process context and no spinlocks are held,
explicitly noted in a mm/memory-failure.c comment.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT
When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in
hard irq context, but the input_event() takes a spin_lock, which isn't
allowed there as it is converted to a rt_spin_lock().
[ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, n ...
In the Linux kernel, the following vulnerability has been resolved:
Input: gpio-keys - fix a sleep while atomic with PREEMPT_RT
When enabling PREEMPT_RT, the gpio_keys_irq_timer() callback runs in
hard irq context, but the input_event() takes a spin_lock, which isn't
allowed there as it is converted to a rt_spin_lock().
[ 4054.289999] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
[ 4054.290028] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/0
...
[ 4054.290195] __might_resched+0x13c/0x1f4
[ 4054.290209] rt_spin_lock+0x54/0x11c
[ 4054.290219] input_event+0x48/0x80
[ 4054.290230] gpio_keys_irq_timer+0x4c/0x78
[ 4054.290243] __hrtimer_run_queues+0x1a4/0x438
[ 4054.290257] hrtimer_interrupt+0xe4/0x240
[ 4054.290269] arch_timer_handler_phys+0x2c/0x44
[ 4054.290283] handle_percpu_devid_irq+0x8c/0x14c
[ 4054.290297] handle_irq_desc+0x40/0x58
[ 4054.290307] generic_handle_domain_irq+0x1c/0x28
[ 4054.290316] gic_handle_irq+0x44/0xcc
Considering the gpio_keys_irq_isr() can run in any context, e.g. it can
be threaded, it seems there's no point in requesting the timer isr to
run in hard irq context.
Relax the hrtimer not to use the hard context.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330
The controller has a hardware bug that can hard hang the system when
doing ATAPI DMAs without any trace of what happened. Depending on the
device attached, it can also prevent the system from booting.
In this case, the system hangs when reading the ATIP from optical media
with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an
Optiarc DVD RW AD-7200A 1.06 att ...
In the Linux kernel, the following vulnerability has been resolved:
ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330
The controller has a hardware bug that can hard hang the system when
doing ATAPI DMAs without any trace of what happened. Depending on the
device attached, it can also prevent the system from booting.
In this case, the system hangs when reading the ATIP from optical media
with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an
Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,
running at UDMA/33.
The issue can be reproduced by running the same command with a cygwin
build of cdrecord on WinXP, although it requires more attempts to cause
it. The hang in that case is also resolved by forcing PIO. It doesn't
appear that VIA has produced any drivers for that OS, thus no known
workaround exists.
HDDs attached to the controller do not suffer from any DMA issues.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()
Since handle->h_transaction may be a NULL pointer, so we should change it
to call is_handle_aborted(handle) first before dereferencing it.
And the following data-race was reported in my fuzzer:
==================================================================
BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata
write to 0x ...
In the Linux kernel, the following vulnerability has been resolved:
jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()
Since handle->h_transaction may be a NULL pointer, so we should change it
to call is_handle_aborted(handle) first before dereferencing it.
And the following data-race was reported in my fuzzer:
==================================================================
BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadata
write to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1:
jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556
__ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358
ext4_do_update_inode fs/ext4/inode.c:5220 [inline]
ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869
__ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074
ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103
....
read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0:
jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512
__ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358
ext4_do_update_inode fs/ext4/inode.c:5220 [inline]
ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869
__ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074
ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103
....
value changed: 0x00000000 -> 0x00000001
==================================================================
This issue is caused by missing data-race annotation for jh->b_modified.
Therefore, the missing annotation needs to be added.
Show More
|
|
In the Linux kernel, the following vulnerability has been resolved:
software node: Correct a OOB check in software_node_get_reference_args()
software_node_get_reference_args() wants to get @index-th element, so
the property value requires at least '(index + 1) * sizeof(*ref)' bytes
but that can not be guaranteed by current OOB check, and may cause OOB
for malformed property.
Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.
|
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: fix acpi parse and parseext cache leaks
ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[ 0.352414] ACPI: Added _OSI(Module Device)
[ 0.353182] ACPI: Added _OSI(Processor Device)
[ ...
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: fix acpi parse and parseext cache leaks
ACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5
I'm Seunghun Han, and I work for National Security Research Institute of
South Korea.
I have been doing a research on ACPI and found an ACPI cache leak in ACPI
early abort cases.
Boot log of ACPI cache leak is as follows:
[ 0.352414] ACPI: Added _OSI(Module Device)
[ 0.353182] ACPI: Added _OSI(Processor Device)
[ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.356028] ACPI: Unable to start the ACPI Interpreter
[ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects
[ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
4.12.0-rc4-next-20170608+ #10
[ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS
virtual_box 12/01/2006
[ 0.361873] Call Trace:
[ 0.362243] ? dump_stack+0x5c/0x81
[ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0
[ 0.362944] ? acpi_sleep_proc_init+0x27/0x27
[ 0.363296] ? acpi_os_delete_cache+0xa/0x10
[ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b
[ 0.364000] ? acpi_terminate+0xa/0x14
[ 0.364000] ? acpi_init+0x2af/0x34f
[ 0.364000] ? __class_create+0x4c/0x80
[ 0.364000] ? video_setup+0x7f/0x7f
[ 0.364000] ? acpi_sleep_proc_init+0x27/0x27
[ 0.364000] ? do_one_initcall+0x4e/0x1a0
[ 0.364000] ? kernel_init_freeable+0x189/0x20a
[ 0.364000] ? rest_init+0xc0/0xc0
[ 0.364000] ? kernel_init+0xa/0x100
[ 0.364000] ? ret_from_fork+0x25/0x30
I analyzed this memory leak in detail. I found that “Acpi-State” cache and
“Acpi-Parse” cache were merged because the size of cache objects was same
slab cache size.
I finally found “Acpi-Parse” cache and “Acpi-parse_ext” cache were leaked
using SLAB_NEVER_MERGE flag in kmem_cache_create() function.
Real ACPI cache leak point is as follows:
[ 0.360101] ACPI: Added _OSI(Module Device)
[ 0.360101] ACPI: Added _OSI(Processor Device)
[ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)
[ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)
[ 0.364016] ACPI: Unable to start the ACPI Interpreter
[ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
[ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects
[ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W
4.12.0-rc4-next-20170608+ #8
[ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS
virtual_box 12/01/2006
[ 0.372000] Call Trace:
[ 0.372000] ? dump_stack+0x5c/0x81
[ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0
[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27
[ 0.372000] ? acpi_os_delete_cache+0xa/0x10
[ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b
[ 0.372000] ? acpi_terminate+0xa/0x14
[ 0.372000] ? acpi_init+0x2af/0x34f
[ 0.372000] ? __class_create+0x4c/0x80
[ 0.372000] ? video_setup+0x7f/0x7f
[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27
[ 0.372000] ? do_one_initcall+0x4e/0x1a0
[ 0.372000] ? kernel_init_freeable+0x189/0x20a
[ 0.372000] ? rest_init+0xc0/0xc0
[ 0.372000] ? kernel_init+0xa/0x100
[ 0.372000] ? ret_from_fork+0x25/0x30
[ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects
[ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W
4.12.0-rc4-next-20170608+ #8
[ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS
virtual_box 12/01/2006
[ 0.392000] Call Trace:
[ 0.392000] ? dump_stack+0x5c/0x81
[ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0
[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27
[ 0.392000] ? acpi_os_delete_cache+0xa/0x10
[ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b
[ 0.392000] ? acpi_terminate+0xa/0x14
[ 0.392000] ? acpi_init+0x2af/0x3
---truncated---
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: fix acpi operand cache leak in dswstate.c
ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI opera ...
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: fix acpi operand cache leak in dswstate.c
ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732
I found an ACPI cache leak in ACPI early termination and boot continuing case.
When early termination occurs due to malicious ACPI table, Linux kernel
terminates ACPI function and continues to boot process. While kernel terminates
ACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.
Boot log of ACPI operand cache leak is as follows:
>[ 0.585957] ACPI: Added _OSI(Module Device)
>[ 0.587218] ACPI: Added _OSI(Processor Device)
>[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)
>[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)
>[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)
>[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)
>[ 0.597858] ACPI: Unable to start the ACPI Interpreter
>[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)
>[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects
>[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26
>[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006
>[ 0.609177] Call Trace:
>[ 0.610063] ? dump_stack+0x5c/0x81
>[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0
>[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27
>[ 0.613906] ? acpi_os_delete_cache+0xa/0x10
>[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b
>[ 0.619293] ? acpi_terminate+0xa/0x14
>[ 0.620394] ? acpi_init+0x2af/0x34f
>[ 0.621616] ? __class_create+0x4c/0x80
>[ 0.623412] ? video_setup+0x7f/0x7f
>[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27
>[ 0.625861] ? do_one_initcall+0x4e/0x1a0
>[ 0.627513] ? kernel_init_freeable+0x19e/0x21f
>[ 0.628972] ? rest_init+0x80/0x80
>[ 0.630043] ? kernel_init+0xa/0x100
>[ 0.631084] ? ret_from_fork+0x25/0x30
>[ 0.633343] vgaarb: loaded
>[ 0.635036] EDAC MC: Ver: 3.0.0
>[ 0.638601] PCI: Probing PCI hardware
>[ 0.639833] PCI host bridge to bus 0000:00
>[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
> ... Continue to boot and log is omitted ...
I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_
delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()
function uses walk_state->operand_index for start position of the top, but
acpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.
Therefore, this causes acpi operand memory leak.
This cache leak causes a security threat because an old kernel (<= 4.9) shows
memory locations of kernel functions in stack dump. Some malicious users
could use this information to neutralize kernel ASLR.
I made a patch to fix ACPI operand cache leak.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix UAF when lookup kallsym after ftrace disabled
The following issue happens with a buggy module:
BUG: unable to handle page fault for address: ffffffffc05d0218
PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0
Oops: Oops: 0000 [#1] SMP KASAN PTI
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
RIP: 0010:sized_strscpy+0x81/0x2f0
RSP: 0018:ffff88812d7 ...
In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix UAF when lookup kallsym after ftrace disabled
The following issue happens with a buggy module:
BUG: unable to handle page fault for address: ffffffffc05d0218
PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0
Oops: Oops: 0000 [#1] SMP KASAN PTI
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
RIP: 0010:sized_strscpy+0x81/0x2f0
RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000
RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d
RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68
R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038
R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff
FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
ftrace_mod_get_kallsym+0x1ac/0x590
update_iter_mod+0x239/0x5b0
s_next+0x5b/0xa0
seq_read_iter+0x8c9/0x1070
seq_read+0x249/0x3b0
proc_reg_read+0x1b0/0x280
vfs_read+0x17f/0x920
ksys_read+0xf3/0x1c0
do_syscall_64+0x5f/0x2e0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
The above issue may happen as follows:
(1) Add kprobe tracepoint;
(2) insmod test.ko;
(3) Module triggers ftrace disabled;
(4) rmmod test.ko;
(5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed;
ftrace_mod_get_kallsym()
...
strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);
...
The problem is when a module triggers an issue with ftrace and
sets ftrace_disable. The ftrace_disable is set when an anomaly is
discovered and to prevent any more damage, ftrace stops all text
modification. The issue that happened was that the ftrace_disable stops
more than just the text modification.
When a module is loaded, its init functions can also be traced. Because
kallsyms deletes the init functions after a module has loaded, ftrace
saves them when the module is loaded and function tracing is enabled. This
allows the output of the function trace to show the init function names
instead of just their raw memory addresses.
When a module is removed, ftrace_release_mod() is called, and if
ftrace_disable is set, it just returns without doing anything more. The
problem here is that it leaves the mod_list still around and if kallsyms
is called, it will call into this code and access the module memory that
has already been freed as it will return:
strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);
Where the "mod" no longer exists and triggers a UAF bug.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
Robert Morris reported:
|If a malicious USB device pretends to be an Intersil p54 wifi
|interface and generates an eeprom_readback message with a large
|eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the
|message beyond the end of priv->eeprom.
|
|static void p54_rx_eeprom_readback(struct p54_common *priv,
| struct s ...
In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()
Robert Morris reported:
|If a malicious USB device pretends to be an Intersil p54 wifi
|interface and generates an eeprom_readback message with a large
|eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the
|message beyond the end of priv->eeprom.
|
|static void p54_rx_eeprom_readback(struct p54_common *priv,
| struct sk_buff *skb)
|{
| struct p54_hdr *hdr = (struct p54_hdr *) skb->data;
| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data;
|
| if (priv->fw_var >= 0x509) {
| memcpy(priv->eeprom, eeprom->v2.data,
| le16_to_cpu(eeprom->v2.len));
| } else {
| memcpy(priv->eeprom, eeprom->v1.data,
| le16_to_cpu(eeprom->v1.len));
| }
| [...]
The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom().
The device is supposed to provide the same length back to the driver.
But yes, it's possible (like shown in the report) to alter the value
to something that causes a crash/panic due to overrun.
This patch addresses the issue by adding the size to the common device
context, so p54_rx_eeprom_readback no longer relies on possibly tampered
values... That said, it also checks if the "firmware" altered the value
and no longer copies them.
The one, small saving grace is: Before the driver tries to read the eeprom,
it needs to upload >a< firmware. the vendor firmware has a proprietary
license and as a reason, it is not present on most distributions by
default.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an
enqueue operation. This may unexpectedly empty the child qdisc and thus
make an in-flight class passive via qlen_notify(). Most qdiscs do not
expect such behaviour at this point in time and may re-activate the
class eventually anyways which will lead to a use-after-free.
The referenced fi ...
In the Linux kernel, the following vulnerability has been resolved:
net/sched: Always pass notifications when child class becomes empty
Certain classful qdiscs may invoke their classes' dequeue handler on an
enqueue operation. This may unexpectedly empty the child qdisc and thus
make an in-flight class passive via qlen_notify(). Most qdiscs do not
expect such behaviour at this point in time and may re-activate the
class eventually anyways which will lead to a use-after-free.
The referenced fix commit attempted to fix this behavior for the HFSC
case by moving the backlog accounting around, though this turned out to
be incomplete since the parent's parent may run into the issue too.
The following reproducer demonstrates this use-after-free:
tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
Since backlog accounting issues leading to a use-after-frees on stale
class pointers is a recurring pattern at this point, this patch takes
a different approach. Instead of trying to fix the accounting, the patch
ensures that qdisc_tree_reduce_backlog always calls qlen_notify when
the child qdisc is empty. This solves the problem because deletion of
qdiscs always involves a call to qdisc_reset() and / or
qdisc_purge_queue() which ultimately resets its qlen to 0 thus causing
the following qdisc_tree_reduce_backlog() to report to the parent. Note
that this may call qlen_notify on passive classes multiple times. This
is not a problem after the recent patch series that made all the
classful qdiscs qlen_notify() handlers idempotent.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix a race between renames and directory logging
We have a race between a rename and directory inode logging that if it
happens and we crash/power fail before the rename completes, the next time
the filesystem is mounted, the log replay code will end up deleting the
file that was being renamed.
This is best explained following a step by step analysis of an interleaving
of steps that lead into this situation.
Consider ...
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix a race between renames and directory logging
We have a race between a rename and directory inode logging that if it
happens and we crash/power fail before the rename completes, the next time
the filesystem is mounted, the log replay code will end up deleting the
file that was being renamed.
This is best explained following a step by step analysis of an interleaving
of steps that lead into this situation.
Consider the initial conditions:
1) We are at transaction N;
2) We have directories A and B created in a past transaction (< N);
3) We have inode X corresponding to a file that has 2 hardlinks, one in
directory A and the other in directory B, so we'll name them as
"A/foo_link1" and "B/foo_link2". Both hard links were persisted in a
past transaction (< N);
4) We have inode Y corresponding to a file that as a single hard link and
is located in directory A, we'll name it as "A/bar". This file was also
persisted in a past transaction (< N).
The steps leading to a file loss are the following and for all of them we
are under transaction N:
1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field
is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir();
2) Task A starts a rename for inode Y, with the goal of renaming from
"A/bar" to "A/baz", so we enter btrfs_rename();
3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling
btrfs_insert_inode_ref();
4) Because the rename happens in the same directory, we don't set the
last_unlink_trans field of directoty A's inode to the current
transaction id, that is, we don't cal btrfs_record_unlink_dir();
5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY
and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode()
(actually the dir index item is added as a delayed item, but the
effect is the same);
6) Now before task A adds the new entry "A/baz" to directory A by
calling btrfs_add_link(), another task, task B is logging inode X;
7) Task B starts a fsync of inode X and after logging inode X, at
btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since
inode X has a last_unlink_trans value of N, set at in step 1;
8) At btrfs_log_all_parents() we search for all parent directories of
inode X using the commit root, so we find directories A and B and log
them. Bu when logging direct A, we don't have a dir index item for
inode Y anymore, neither the old name "A/bar" nor for the new name
"A/baz" since the rename has deleted the old name but has not yet
inserted the new name - task A hasn't called yet btrfs_add_link() to
do that.
Note that logging directory A doesn't fallback to a transaction
commit because its last_unlink_trans has a lower value than the
current transaction's id (see step 4);
9) Task B finishes logging directories A and B and gets back to
btrfs_sync_file() where it calls btrfs_sync_log() to persist the log
tree;
10) Task B successfully persisted the log tree, btrfs_sync_log() completed
with success, and a power failure happened.
We have a log tree without any directory entry for inode Y, so the
log replay code deletes the entry for inode Y, name "A/bar", from the
subvolume tree since it doesn't exist in the log tree and the log
tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY
item that covers the index range for the dentry that corresponds to
"A/bar").
Since there's no other hard link for inode Y and the log replay code
deletes the name "A/bar", the file is lost.
The issue wouldn't happen if task B synced the log only after task A
called btrfs_log_new_name(), which would update the log with the new name
for inode Y ("A/bar").
Fix this by pinning the log root during renames before removing the old
directory entry, and unpinning af
---truncated---
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Disable interrupts before resetting the GPU
Currently, an interrupt can be triggered during a GPU reset, which can
lead to GPU hangs and NULL pointer dereference in an interrupt context
as shown in the following trace:
[ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0
[ 314.043822] Mem abort info:
[ 314.046606] ESR = 0x0000000096000005
[ 314.050347] EC = 0x ...
In the Linux kernel, the following vulnerability has been resolved:
drm/v3d: Disable interrupts before resetting the GPU
Currently, an interrupt can be triggered during a GPU reset, which can
lead to GPU hangs and NULL pointer dereference in an interrupt context
as shown in the following trace:
[ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0
[ 314.043822] Mem abort info:
[ 314.046606] ESR = 0x0000000096000005
[ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits
[ 314.055651] SET = 0, FnV = 0
[ 314.058695] EA = 0, S1PTW = 0
[ 314.061826] FSC = 0x05: level 1 translation fault
[ 314.066694] Data abort info:
[ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000
[ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight
[ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1
[ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d]
[ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d]
[ 314.160198] sp : ffffffc080003ea0
[ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000
[ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0
[ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000
[ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000
[ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000
[ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001
[ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874
[ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180
[ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb
[ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
[ 314.234807] Call trace:
[ 314.237243] v3d_irq+0xec/0x2e0 [v3d]
[ 314.240906] __handle_irq_event_percpu+0x58/0x218
[ 314.245609] handle_irq_event+0x54/0xb8
[ 314.249439] handle_fasteoi_irq+0xac/0x240
[ 314.253527] handle_irq_desc+0x48/0x68
[ 314.257269] generic_handle_domain_irq+0x24/0x38
[ 314.261879] gic_handle_irq+0x48/0xd8
[ 314.265533] call_on_irq_stack+0x24/0x58
[ 314.269448] do_interrupt_handler+0x88/0x98
[ 314.273624] el1_interrupt+0x34/0x68
[ 314.277193] el1h_64_irq_handler+0x18/0x28
[ 314.281281] el1h_64_irq+0x64/0x68
[ 314.284673] default_idle_call+0x3c/0x168
[ 314.288675] do_idle+0x1fc/0x230
[ 314.291895] cpu_startup_entry+0x3c/0x50
[ 314.295810] rest_init+0xe4/0xf0
[ 314.299030] start_kernel+0x5e8/0x790
[ 314.302684] __primary_switched+0x80/0x90
[ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017)
[ 314.312775] ---[ end trace 0000000000000000 ]---
[ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt
[ 314.324249] SMP: stopping secondary CPUs
[ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000
[ 314.334076] PHYS_OFFSET: 0x0
[ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b
[ 314.342337] Memory Limit: none
[ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
Before resetting the G
---truncated---
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macb_halt_tx.
There is a situation where after THALT is set high, TGO stays high as
well. Because jiffies are never updated, as we are in a context with
interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do
not have a de ...
In the Linux kernel, the following vulnerability has been resolved:
net: cadence: macb: Fix a possible deadlock in macb_halt_tx.
There is a situation where after THALT is set high, TGO stays high as
well. Because jiffies are never updated, as we are in a context with
interrupts disabled, we never exit that loop and have a deadlock.
That deadlock was noticed on a sama5d4 device that stayed locked for days.
Use retries instead of jiffies so that the timeout really works and we do
not have a deadlock anymore.
Show More
|
|
In the Linux kernel, the following vulnerability has been resolved:
dma-buf: insert memory barrier before updating num_fences
smp_store_mb() inserts memory barrier after storing operation.
It is different with what the comment is originally aiming so Null
pointer dereference can be happened if memory update is reordered.
|
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference
leaks when we try to delete the netns.
The reference chain is: xfrm_state -> enacp_sk -> netns
Since the encap socket is a userspace socket, it holds a reference on
the netns. If we delete the espintcp state (through flush or
individual delete) before removing the netns, the reference on the
soc ...
In the Linux kernel, the following vulnerability has been resolved:
espintcp: remove encap socket caching to avoid reference leak
The current scheme for caching the encap socket can lead to reference
leaks when we try to delete the netns.
The reference chain is: xfrm_state -> enacp_sk -> netns
Since the encap socket is a userspace socket, it holds a reference on
the netns. If we delete the espintcp state (through flush or
individual delete) before removing the netns, the reference on the
socket is dropped and the netns is correctly deleted. Otherwise, the
netns may not be reachable anymore (if all processes within the ns
have terminated), so we cannot delete the xfrm state to drop its
reference on the socket.
This patch results in a small (~2% in my tests) performance
regression.
A GC-type mechanism could be added for the socket cache, to clear
references if the state hasn't been used "recently", but it's a lot
more complex than just not caching the socket.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
io_bitmap_exit() is invoked from exit_thread() when a task exists or
when a fork fails. In the latter case the exit_thread() cleans up
resources which were allocated during fork().
io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up
in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the
current task. If current has TIF_IO_BITMAP set, but no bitmap ins ...
In the Linux kernel, the following vulnerability has been resolved:
x86/iopl: Cure TIF_IO_BITMAP inconsistencies
io_bitmap_exit() is invoked from exit_thread() when a task exists or
when a fork fails. In the latter case the exit_thread() cleans up
resources which were allocated during fork().
io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends up
in tss_update_io_bitmap(). tss_update_io_bitmap() operates on the
current task. If current has TIF_IO_BITMAP set, but no bitmap installed,
tss_update_io_bitmap() crashes with a NULL pointer dereference.
There are two issues, which lead to that problem:
1) io_bitmap_exit() should not invoke task_update_io_bitmap() when
the task, which is cleaned up, is not the current task. That's a
clear indicator for a cleanup after a failed fork().
2) A task should not have TIF_IO_BITMAP set and neither a bitmap
installed nor IOPL emulation level 3 activated.
This happens when a kernel thread is created in the context of
a user space thread, which has TIF_IO_BITMAP set as the thread
flags are copied and the IO bitmap pointer is cleared.
Other than in the failed fork() case this has no impact because
kernel threads including IO workers never return to user space and
therefore never invoke tss_update_io_bitmap().
Cure this by adding the missing cleanups and checks:
1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if
the to be cleaned up task is not the current task.
2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user
space forks it is set later, when the IO bitmap is inherited in
io_bitmap_share().
For paranoia sake, add a warning into tss_update_io_bitmap() to catch
the case, when that code is invoked with inconsistent state.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio
as follow:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
Modules linked in:
CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
RIP: 0010:try_grab_folio+0x106/0x130
Call Trace:
...
In the Linux kernel, the following vulnerability has been resolved:
VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notify
During our test, it is found that a warning can be trigger in try_grab_folio
as follow:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130
Modules linked in:
CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef)
RIP: 0010:try_grab_folio+0x106/0x130
Call Trace:
<TASK>
follow_huge_pmd+0x240/0x8e0
follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0
follow_pud_mask.constprop.0.isra.0+0x14a/0x170
follow_page_mask+0x1c2/0x1f0
__get_user_pages+0x176/0x950
__gup_longterm_locked+0x15b/0x1060
? gup_fast+0x120/0x1f0
gup_fast_fallback+0x17e/0x230
get_user_pages_fast+0x5f/0x80
vmci_host_unlocked_ioctl+0x21c/0xf80
RIP: 0033:0x54d2cd
---[ end trace 0000000000000000 ]---
Digging into the source, context->notify_page may init by get_user_pages_fast
and can be seen in vmci_ctx_unset_notify which will try to put_page. However
get_user_pages_fast is not finished here and lead to following
try_grab_folio warning. The race condition is shown as follow:
cpu0 cpu1
vmci_host_do_set_notify
vmci_host_setup_notify
get_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);
lockless_pages_from_mm
gup_pgd_range
gup_huge_pmd // update &context->notify_page
vmci_host_do_set_notify
vmci_ctx_unset_notify
notify_page = context->notify_page;
if (notify_page)
put_page(notify_page); // page is freed
__gup_longterm_locked
__get_user_pages
follow_trans_huge_pmd
try_grab_folio // warn here
To slove this, use local variable page to make notify_page can be seen
after finish get_user_pages_fast.
Show More
|
|
In the Linux kernel, the following vulnerability has been resolved:
virtio-net: ensure the received length does not exceed allocated size
In xdp_linearize_page, when reading the following buffers from the ring,
we forget to check the received length with the true allocate size. This
can lead to an out-of-bound read. This commit adds that missing check.
|
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()
Update struct hid_descriptor to better reflect the mandatory and
optional parts of the HID Descriptor as per USB HID 1.11 specification.
Note: the kernel currently does not parse any optional HID class
descriptors, only the mandatory report descriptor.
Update all references to member element desc[0] to rpt_desc.
Add test to verify bLength and bNumDescriptor ...
In the Linux kernel, the following vulnerability has been resolved:
HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()
Update struct hid_descriptor to better reflect the mandatory and
optional parts of the HID Descriptor as per USB HID 1.11 specification.
Note: the kernel currently does not parse any optional HID class
descriptors, only the mandatory report descriptor.
Update all references to member element desc[0] to rpt_desc.
Add test to verify bLength and bNumDescriptors values are valid.
Replace the for loop with direct access to the mandatory HID class
descriptor member for the report descriptor. This eliminates the
possibility of getting an out-of-bounds fault.
Add a warning message if the HID descriptor contains any unsupported
optional HID class descriptors.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
net_sched: ets: fix a race in ets_qdisc_change()
Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer
fires at the wrong time.
The race is as follows:
CPU 0 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
|
| [5]: lock root
| [6]: rehash
| [7]: ...
In the Linux kernel, the following vulnerability has been resolved:
net_sched: ets: fix a race in ets_qdisc_change()
Gerrard Tai reported a race condition in ETS, whenever SFQ perturb timer
fires at the wrong time.
The race is as follows:
CPU 0 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
|
| [5]: lock root
| [6]: rehash
| [7]: qdisc_tree_reduce_backlog()
|
[4]: qdisc_put()
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
net_sched: red: fix a race in __red_change()
Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer
fires at the wrong time.
The race is as follows:
CPU 0 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
|
| [5]: lock root
| [6]: rehash
| [7]: qdis ...
In the Linux kernel, the following vulnerability has been resolved:
net_sched: red: fix a race in __red_change()
Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer
fires at the wrong time.
The race is as follows:
CPU 0 CPU 1
[1]: lock root
[2]: qdisc_tree_flush_backlog()
[3]: unlock root
|
| [5]: lock root
| [6]: rehash
| [7]: qdisc_tree_reduce_backlog()
|
[4]: qdisc_put()
This can be abused to underflow a parent's qlen.
Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()
should fix the race, because all packets will be purged from the qdisc
before releasing the lock.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed
a problem in the way tcp handles window advertising in extreme memory
squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise
a zero-sized window, but this is not stored as part of the socket data.
The reasoning behind this is that it is considered a temporary setting
which shouldn ...
In the Linux kernel, the following vulnerability has been resolved:
tcp: correct handling of extreme memory squeeze
Testing with iperf3 using the "pasta" protocol splicer has revealed
a problem in the way tcp handles window advertising in extreme memory
squeeze situations.
Under memory pressure, a socket endpoint may temporarily advertise
a zero-sized window, but this is not stored as part of the socket data.
The reasoning behind this is that it is considered a temporary setting
which shouldn't influence any further calculations.
However, if we happen to stall at an unfortunate value of the current
window size, the algorithm selecting a new value will consistently fail
to advertise a non-zero window once we have freed up enough memory.
This means that this side's notion of the current window size is
different from the one last advertised to the peer, causing the latter
to not send any data to resolve the sitution.
The problem occurs on the iperf3 server side, and the socket in question
is a completely regular socket with the default settings for the
fedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.
The following excerpt of a logging session, with own comments added,
shows more in detail what is happening:
// tcp_v4_rcv(->)
// tcp_rcv_established(->)
[5201<->39222]: ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====
[5201<->39222]: tcp_data_queue(->)
[5201<->39222]: DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM
[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
[copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0]
[OFO queue: gap: 65480, len: 0]
[5201<->39222]: tcp_data_queue(<-)
[5201<->39222]: __tcp_transmit_skb(->)
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
[5201<->39222]: tcp_select_window(->)
[5201<->39222]: (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
returning 0
[5201<->39222]: tcp_select_window(<-)
[5201<->39222]: ADVERTISING WIN 0, ACK_SEQ: 265600160
[5201<->39222]: [__tcp_transmit_skb(<-)
[5201<->39222]: tcp_rcv_established(<-)
[5201<->39222]: tcp_v4_rcv(<-)
// Receive queue is at 85 buffers and we are out of memory.
// We drop the incoming buffer, although it is in sequence, and decide
// to send an advertisement with a window of zero.
// We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means
// we unconditionally shrink the window.
[5201<->39222]: tcp_recvmsg_locked(->)
[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160
[5201<->39222]: [new_win = 0, win_now = 131184, 2 * win_now = 262368]
[5201<->39222]: [new_win >= (2 * win_now) ? --> time_to_ack = 0]
[5201<->39222]: NOT calling tcp_send_ack()
[tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]
[5201<->39222]: __tcp_cleanup_rbuf(<-)
[rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]
[copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]
returning 6104 bytes
[5201<->39222]: tcp_recvmsg_locked(<-)
// After each read, the algorithm for calculating the new receive
// window in __tcp_cleanup_rbuf() finds it is too small to advertise
// or to update tp->rcv_wnd.
// Meanwhile, the peer thinks the window is zero, and will not send
// any more data to trigger an update from the interrupt mode side.
[5201<->39222]: tcp_recvmsg_locked(->)
[5201<->39222]: __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160
[5201<->39222]: [new_win = 262144, win_now = 131184, 2 * win_n
---truncated---
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds read/write access
When using publicly available tools like 'mdio-tools' to read/write data
from/to network interface and its PHY via mdiobus, there is no verification of
parameters passed to the ioctl and it accepts any mdio address.
Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,
but it is possible to pass higher value than that via ioctl.
While read/writ ...
In the Linux kernel, the following vulnerability has been resolved:
net/mdiobus: Fix potential out-of-bounds read/write access
When using publicly available tools like 'mdio-tools' to read/write data
from/to network interface and its PHY via mdiobus, there is no verification of
parameters passed to the ioctl and it accepts any mdio address.
Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,
but it is possible to pass higher value than that via ioctl.
While read/write operation should generally fail in this case,
mdiobus provides stats array, where wrong address may allow out-of-bounds
read/write.
Fix that by adding address verification before read/write operation.
While this excludes this access from any statistics, it improves security of
read/write operation.
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/gpu: Fix crash when throttling GPU immediately during boot
There is a small chance that the GPU is already hot during boot. In that
case, the call to of_devfreq_cooling_register() will immediately try to
apply devfreq cooling, as seen in the following crash:
Unable to handle kernel paging request at virtual address 0000000000014110
pc : a6xx_gpu_busy+0x1c/0x58 [msm]
lr : msm_devfreq_get_dev_status+0xbc/0x140 [ms ...
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/gpu: Fix crash when throttling GPU immediately during boot
There is a small chance that the GPU is already hot during boot. In that
case, the call to of_devfreq_cooling_register() will immediately try to
apply devfreq cooling, as seen in the following crash:
Unable to handle kernel paging request at virtual address 0000000000014110
pc : a6xx_gpu_busy+0x1c/0x58 [msm]
lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]
Call trace:
a6xx_gpu_busy+0x1c/0x58 [msm] (P)
devfreq_simple_ondemand_func+0x3c/0x150
devfreq_update_target+0x44/0xd8
qos_max_notifier_call+0x30/0x84
blocking_notifier_call_chain+0x6c/0xa0
pm_qos_update_target+0xd0/0x110
freq_qos_apply+0x3c/0x74
apply_constraint+0x88/0x148
__dev_pm_qos_update_request+0x7c/0xcc
dev_pm_qos_update_request+0x38/0x5c
devfreq_cooling_set_cur_state+0x98/0xf0
__thermal_cdev_update+0x64/0xb4
thermal_cdev_update+0x4c/0x58
step_wise_manage+0x1f0/0x318
__thermal_zone_device_update+0x278/0x424
__thermal_cooling_device_register+0x2bc/0x308
thermal_of_cooling_device_register+0x10/0x1c
of_devfreq_cooling_register_power+0x240/0x2bc
of_devfreq_cooling_register+0x14/0x20
msm_devfreq_init+0xc4/0x1a0 [msm]
msm_gpu_init+0x304/0x574 [msm]
adreno_gpu_init+0x1c4/0x2e0 [msm]
a6xx_gpu_init+0x5c8/0x9c8 [msm]
adreno_bind+0x2a8/0x33c [msm]
...
At this point we haven't initialized the GMU at all yet, so we cannot read
the GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before
in commit 6694482a70e9 ("drm/msm: Avoid unclocked GMU register access in
6xx gpu_busy"): msm_devfreq_init() does call devfreq_suspend_device(), but
unlike msm_devfreq_suspend(), it doesn't set the df->suspended flag
accordingly. This means the df->suspended flag does not match the actual
devfreq state after initialization and msm_devfreq_get_dev_status() will
end up accessing GMU registers, causing the crash.
Fix this by setting df->suspended correctly during initialization.
Patchwork: https://patchwork.freedesktop.org/patch/650772/
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null pointer check for get_first_active_display()
The function mod_hdcp_hdcp1_enable_encryption() calls the function
get_first_active_display(), but does not check its return value.
The return value is a null pointer if the display list is empty.
This will lead to a null pointer dereference in
mod_hdcp_hdcp2_enable_encryption().
Add a null pointer check for get_first_active_display() and return
MOD_HDCP_S ...
In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null pointer check for get_first_active_display()
The function mod_hdcp_hdcp1_enable_encryption() calls the function
get_first_active_display(), but does not check its return value.
The return value is a null pointer if the display list is empty.
This will lead to a null pointer dereference in
mod_hdcp_hdcp2_enable_encryption().
Add a null pointer check for get_first_active_display() and return
MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.
Show More
|
|
In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: Fix a possible null pointer dereference
In tegra_crtc_reset(), new memory is allocated with kzalloc(), but
no check is performed. Before calling __drm_atomic_helper_crtc_reset,
state should be checked to prevent possible null pointer dereference.
|
In the Linux kernel, the following vulnerability has been resolved:
maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()
Temporarily clear the preallocation flag when explicitly requesting
allocations. Pre-existing allocations are already counted against the
request through mas_node_count_gfp(), but the allocations will not happen
if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid
re-allocating in bulk allocation mode, and to detect issues with
preallocation calculation ...
In the Linux kernel, the following vulnerability has been resolved:
maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate()
Temporarily clear the preallocation flag when explicitly requesting
allocations. Pre-existing allocations are already counted against the
request through mas_node_count_gfp(), but the allocations will not happen
if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid
re-allocating in bulk allocation mode, and to detect issues with
preallocation calculations.
The MA_STATE_PREALLOC flag should also always be set on zero allocations
so that detection of underflow allocations will print a WARN_ON() during
consumption.
User visible effect of this flaw is a WARN_ON() followed by a null pointer
dereference when subsequent requests for larger number of nodes is
ignored, such as the vma merge retry in mmap_region() caused by drivers
altering the vma flags (which happens in v6.6, at least)
Show More
|
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi
The following assertion is triggered on the rtw89 driver startup. It
looks meaningless to hold wiphy lock on the early init stage so drop the
assertion.
WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]
CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy)
Ha ...
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi
The following assertion is triggered on the rtw89 driver startup. It
looks meaningless to hold wiphy lock on the early init stage so drop the
assertion.
WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]
CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy)
Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024
RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]
Call Trace:
<TASK>
rtw89_sar_init+0x68/0x2c0 [rtw89_core]
rtw89_core_init+0x188e/0x1e50 [rtw89_core]
rtw89_pci_probe+0x530/0xb50 [rtw89_pci]
local_pci_probe+0xd9/0x190
pci_call_probe+0x183/0x540
pci_device_probe+0x171/0x2c0
really_probe+0x1e1/0x890
__driver_probe_device+0x18c/0x390
driver_probe_device+0x4a/0x120
__driver_attach+0x1a0/0x530
bus_for_each_dev+0x10b/0x190
bus_add_driver+0x2eb/0x540
driver_register+0x1a3/0x3a0
do_one_initcall+0xd5/0x450
do_init_module+0x2cc/0x8f0
init_module_from_file+0xe1/0x150
idempotent_init_module+0x226/0x760
__x64_sys_finit_module+0xcd/0x150
do_syscall_64+0x94/0x380
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Found by Linux Verification Center (linuxtesting.org).
Show More
|
|
Transmission of Private Resources into a New Sphere ('Resource Leak') vulnerability in CrafterCMS Engine on Linux, MacOS, x86, Windows, 64 bit, ARM allows Directory Indexing, Resource Leak Exposure.This issue affects CrafterCMS: from 4.0.0 before 4.0.8, from 4.1.0 before 4.1.6.
|
|
In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: Add check for rgby_data memory allocation failure
In ia_css_3a_statistics_allocate(), there is no check on the allocation
result of the rgby_data memory. If rgby_data is not successfully
allocated, it may trigger the assert(host_stats->rgby_data) assertion in
ia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.
|
|
IBM Aspera Orchestrator 4.0.0 through 4.1.0 could allow could an authenticated user to change the password of another user without prior knowledge of that password.
|
|
IBM Aspera Orchestrator 4.0.0 through 4.1.0 could allow an authenticated user to cause a denial of service in the email service due to improper control of interaction frequency.
|
|
IBM Aspera Orchestrator 4.0.0 through 4.1.0 is vulnerable to SQL injection. A remote attacker could send specially crafted SQL statements, which could allow the attacker to view, add, modify, or delete information in the back-end database.
|
