| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
media: airspy: fix memory leak in airspy probe
The commit ca9dc8d06ab6 ("media: airspy: respect the DMA coherency
rules") moves variable buf from stack to heap, however, it only frees
buf in the error handling code, missing deallocation in the success
path.
Fix this by freeing buf in the success path since this variable does not
have any references in other code. |
| In the Linux kernel, the following vulnerability has been resolved:
mtd: maps: pxa2xx-flash: fix memory leak in probe
Free 'info' upon remapping error to avoid a memory leak.
[<miquel.raynal@bootlin.com>: Reword the commit log] |
| In the Linux kernel, the following vulnerability has been resolved:
orangefs: Fix kmemleak in orangefs_sysfs_init()
When insert and remove the orangefs module, there are kobjects memory
leaked as below:
unreferenced object 0xffff88810f95af00 (size 64):
comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)
hex dump (first 32 bytes):
a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................
08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000031ab7788>] kmalloc_trace+0x27/0xa0
[<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0
[<00000000722645ca>] 0xffffffffa02780fe
[<000000004232d9f7>] do_one_initcall+0x87/0x2a0
[<0000000054f22384>] do_init_module+0xdf/0x320
[<000000003263bdea>] load_module+0x2f98/0x3330
[<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
[<00000000250ae02b>] do_syscall_64+0x35/0x80
[<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
unreferenced object 0xffff88810f95ae80 (size 64):
comm "insmod", pid 783, jiffies 4294813439 (age 65.512s)
hex dump (first 32 bytes):
c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................
88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000031ab7788>] kmalloc_trace+0x27/0xa0
[<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0
[<00000000722645ca>] 0xffffffffa02780fe
[<000000004232d9f7>] do_one_initcall+0x87/0x2a0
[<0000000054f22384>] do_init_module+0xdf/0x320
[<000000003263bdea>] load_module+0x2f98/0x3330
[<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
[<00000000250ae02b>] do_syscall_64+0x35/0x80
[<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
unreferenced object 0xffff88810f95ae00 (size 64):
comm "insmod", pid 783, jiffies 4294813440 (age 65.511s)
hex dump (first 32 bytes):
60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `...............
08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000031ab7788>] kmalloc_trace+0x27/0xa0
[<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0
[<00000000722645ca>] 0xffffffffa02780fe
[<000000004232d9f7>] do_one_initcall+0x87/0x2a0
[<0000000054f22384>] do_init_module+0xdf/0x320
[<000000003263bdea>] load_module+0x2f98/0x3330
[<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
[<00000000250ae02b>] do_syscall_64+0x35/0x80
[<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
unreferenced object 0xffff88810f95ad80 (size 64):
comm "insmod", pid 783, jiffies 4294813440 (age 65.511s)
hex dump (first 32 bytes):
78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x...............
88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000031ab7788>] kmalloc_trace+0x27/0xa0
[<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0
[<00000000722645ca>] 0xffffffffa02780fe
[<000000004232d9f7>] do_one_initcall+0x87/0x2a0
[<0000000054f22384>] do_init_module+0xdf/0x320
[<000000003263bdea>] load_module+0x2f98/0x3330
[<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
[<00000000250ae02b>] do_syscall_64+0x35/0x80
[<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
unreferenced object 0xffff88810f95ac00 (size 64):
comm "insmod", pid 783, jiffies 4294813440 (age 65.531s)
hex dump (first 32 bytes):
e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g.............
08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000031ab7788>] kmalloc_trace+0x27/0xa0
[<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0
[<00000000722645ca>] 0xffffffffa02780fe
[<000000004232d9f7>] do_one_initcall+0x87/0x2a0
[<0000000054f22384>] do_init_module+0xdf/0x320
[<000000003263bdea>] load_module+0x2f98/0x3330
[<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0
[<00000000250ae02b>] do_syscall_64+0x35/
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix memory leak in lbs_init_adapter()
When kfifo_alloc() failed in lbs_init_adapter(), cmd buffer is not
released. Add free memory to processing error path. |
| In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix memory leak in ocfs2_stack_glue_init()
ocfs2_table_header should be free in ocfs2_stack_glue_init() if
ocfs2_sysfs_init() failed, otherwise kmemleak will report memleak.
BUG: memory leak
unreferenced object 0xffff88810eeb5800 (size 128):
comm "modprobe", pid 4507, jiffies 4296182506 (age 55.888s)
hex dump (first 32 bytes):
c0 40 14 a0 ff ff ff ff 00 00 00 00 01 00 00 00 .@..............
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<000000001e59e1cd>] __register_sysctl_table+0xca/0xef0
[<00000000c04f70f7>] 0xffffffffa0050037
[<000000001bd12912>] do_one_initcall+0xdb/0x480
[<0000000064f766c9>] do_init_module+0x1cf/0x680
[<000000002ba52db0>] load_module+0x6441/0x6f20
[<000000009772580d>] __do_sys_finit_module+0x12f/0x1c0
[<00000000380c1f22>] do_syscall_64+0x3f/0x90
[<000000004cf473bc>] entry_SYSCALL_64_after_hwframe+0x63/0xcd |
| In the Linux kernel, the following vulnerability has been resolved:
qlcnic: prevent ->dcb use-after-free on qlcnic_dcb_enable() failure
adapter->dcb would get silently freed inside qlcnic_dcb_enable() in
case qlcnic_dcb_attach() would return an error, which always happens
under OOM conditions. This would lead to use-after-free because both
of the existing callers invoke qlcnic_dcb_get_info() on the obtained
pointer, which is potentially freed at that point.
Propagate errors from qlcnic_dcb_enable(), and instead free the dcb
pointer at callsite using qlcnic_dcb_free(). This also removes the now
unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around
kfree() also causing memory leaks for partially initialized dcb.
Found by Linux Verification Center (linuxtesting.org) with the SVACE
static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
ipc: fix memory leak in init_mqueue_fs()
When setup_mq_sysctls() failed in init_mqueue_fs(), mqueue_inode_cachep is
not released. In order to fix this issue, the release path is reordered. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: don't allow journal inode to have encrypt flag
Mounting a filesystem whose journal inode has the encrypt flag causes a
NULL dereference in fscrypt_limit_io_blocks() when the 'inlinecrypt'
mount option is used.
The problem is that when jbd2_journal_init_inode() calls bmap(), it
eventually finds its way into ext4_iomap_begin(), which calls
fscrypt_limit_io_blocks(). fscrypt_limit_io_blocks() requires that if
the inode is encrypted, then its encryption key must already be set up.
That's not the case here, since the journal inode is never "opened" like
a normal file would be. Hence the crash.
A reproducer is:
mkfs.ext4 -F /dev/vdb
debugfs -w /dev/vdb -R "set_inode_field <8> flags 0x80808"
mount /dev/vdb /mnt -o inlinecrypt
To fix this, make ext4 consider journal inodes with the encrypt flag to
be invalid. (Note, maybe other flags should be rejected on the journal
inode too. For now, this is just the minimal fix for the above issue.)
I've marked this as fixing the commit that introduced the call to
fscrypt_limit_io_blocks(), since that's what made an actual crash start
being possible. But this fix could be applied to any version of ext4
that supports the encrypt feature. |
| In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on destination blkaddr during recovery
As Wenqing Liu reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=216456
loop5: detected capacity change from 0 to 131072
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1
F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0
F2FS-fs (loop5): Bitmap was wrongly set, blk:5634
------------[ cut here ]------------
WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198
RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]
Call Trace:
<TASK>
f2fs_do_replace_block+0xa98/0x1890 [f2fs]
f2fs_replace_block+0xeb/0x180 [f2fs]
recover_data+0x1a69/0x6ae0 [f2fs]
f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]
f2fs_fill_super+0x4665/0x61e0 [f2fs]
mount_bdev+0x2cf/0x3b0
legacy_get_tree+0xed/0x1d0
vfs_get_tree+0x81/0x2b0
path_mount+0x47e/0x19d0
do_mount+0xce/0xf0
__x64_sys_mount+0x12c/0x1a0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic
instead of warning.
The root cause is: in fuzzed image, SIT table is inconsistent with inode
mapping table, result in triggering such warning during SIT table update.
This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this
flag, data block recovery flow can check destination blkaddr's validation
in SIT table, and skip f2fs_replace_block() to avoid inconsistent status. |
| In the Linux kernel, the following vulnerability has been resolved:
vhost/vsock: Use kvmalloc/kvfree for larger packets.
When copying a large file over sftp over vsock, data size is usually 32kB,
and kmalloc seems to fail to try to allocate 32 32kB regions.
vhost-5837: page allocation failure: order:4, mode:0x24040c0
Call Trace:
[<ffffffffb6a0df64>] dump_stack+0x97/0xdb
[<ffffffffb68d6aed>] warn_alloc_failed+0x10f/0x138
[<ffffffffb68d868a>] ? __alloc_pages_direct_compact+0x38/0xc8
[<ffffffffb664619f>] __alloc_pages_nodemask+0x84c/0x90d
[<ffffffffb6646e56>] alloc_kmem_pages+0x17/0x19
[<ffffffffb6653a26>] kmalloc_order_trace+0x2b/0xdb
[<ffffffffb66682f3>] __kmalloc+0x177/0x1f7
[<ffffffffb66e0d94>] ? copy_from_iter+0x8d/0x31d
[<ffffffffc0689ab7>] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock]
[<ffffffffc06828d9>] vhost_worker+0xf7/0x157 [vhost]
[<ffffffffb683ddce>] kthread+0xfd/0x105
[<ffffffffc06827e2>] ? vhost_dev_set_owner+0x22e/0x22e [vhost]
[<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3
[<ffffffffb6eb332e>] ret_from_fork+0x4e/0x80
[<ffffffffb683dcd1>] ? flush_kthread_worker+0xf3/0xf3
Work around by doing kvmalloc instead. |
| In the Linux kernel, the following vulnerability has been resolved:
mmc: moxart: fix return value check of mmc_add_host()
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(). |
| In the Linux kernel, the following vulnerability has been resolved:
kcm: annotate data-races around kcm->rx_wait
kcm->rx_psock can be read locklessly in kcm_rfree().
Annotate the read and writes accordingly.
syzbot reported:
BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfree
write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:
reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]
kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363
__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301
strp_recv+0x6d/0x80 net/strparser/strparser.c:335
tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703
strp_read_sock net/strparser/strparser.c:358 [inline]
do_strp_work net/strparser/strparser.c:406 [inline]
strp_work+0xe8/0x180 net/strparser/strparser.c:415
process_one_work+0x3d3/0x720 kernel/workqueue.c:2289
worker_thread+0x618/0xa70 kernel/workqueue.c:2436
kthread+0x1a9/0x1e0 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:
kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181
skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841
skb_release_all net/core/skbuff.c:852 [inline]
__kfree_skb net/core/skbuff.c:868 [inline]
kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891
kfree_skb include/linux/skbuff.h:1216 [inline]
kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161
____sys_recvmsg+0x16c/0x2e0
___sys_recvmsg net/socket.c:2743 [inline]
do_recvmmsg+0x2f1/0x710 net/socket.c:2837
__sys_recvmmsg net/socket.c:2916 [inline]
__do_sys_recvmmsg net/socket.c:2939 [inline]
__se_sys_recvmmsg net/socket.c:2932 [inline]
__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x01 -> 0x00
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 |
| In the Linux kernel, the following vulnerability has been resolved:
net: hibmcge: fix the division by zero issue
When the network port is down, the queue is released, and ring->len is 0.
In debugfs, hbg_get_queue_used_num() will be called,
which may lead to a division by zero issue.
This patch adds a check, if ring->len is 0,
hbg_get_queue_used_num() directly returns 0. |
| In the Linux kernel, the following vulnerability has been resolved:
clk: socfpga: Fix memory leak in socfpga_gate_init()
Free @socfpga_clk and @ops on the error path to avoid memory leak issue. |
| In the Linux kernel, the following vulnerability has been resolved:
vdpasim: fix memory leak when freeing IOTLBs
After commit bda324fd037a ("vdpasim: control virtqueue support"),
vdpasim->iommu became an array of IOTLB, so we should clean the
mappings of each free one by one instead of just deleting the ranges
in the first IOTLB which may leak maps. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate BOOT record_size
When the NTFS BOOT record_size field < 0, it represents a
shift value. However, there is no sanity check on the shift result
and the sbi->record_bits calculation through blksize_bits() assumes
the size always > 256, which could lead to NPD while mounting a
malformed NTFS image.
[ 318.675159] BUG: kernel NULL pointer dereference, address: 0000000000000158
[ 318.675682] #PF: supervisor read access in kernel mode
[ 318.675869] #PF: error_code(0x0000) - not-present page
[ 318.676246] PGD 0 P4D 0
[ 318.676502] Oops: 0000 [#1] PREEMPT SMP NOPTI
[ 318.676934] CPU: 0 PID: 259 Comm: mount Not tainted 5.19.0 #5
[ 318.677289] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[ 318.678136] RIP: 0010:ni_find_attr+0x2d/0x1c0
[ 318.678656] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180
[ 318.679848] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246
[ 318.680104] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080
[ 318.680790] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 318.681679] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 318.682577] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080
[ 318.683015] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000
[ 318.683618] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000
[ 318.684280] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 318.684651] CR2: 0000000000000158 CR3: 0000000002e1a000 CR4: 00000000000006f0
[ 318.685623] Call Trace:
[ 318.686607] <TASK>
[ 318.686872] ? ntfs_alloc_inode+0x1a/0x60
[ 318.687235] attr_load_runs_vcn+0x2b/0xa0
[ 318.687468] mi_read+0xbb/0x250
[ 318.687576] ntfs_iget5+0x114/0xd90
[ 318.687750] ntfs_fill_super+0x588/0x11b0
[ 318.687953] ? put_ntfs+0x130/0x130
[ 318.688065] ? snprintf+0x49/0x70
[ 318.688164] ? put_ntfs+0x130/0x130
[ 318.688256] get_tree_bdev+0x16a/0x260
[ 318.688407] vfs_get_tree+0x20/0xb0
[ 318.688519] path_mount+0x2dc/0x9b0
[ 318.688877] do_mount+0x74/0x90
[ 318.689142] __x64_sys_mount+0x89/0xd0
[ 318.689636] do_syscall_64+0x3b/0x90
[ 318.689998] entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 318.690318] RIP: 0033:0x7fd9e133c48a
[ 318.690687] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008
[ 318.691357] RSP: 002b:00007ffd374406c8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5
[ 318.691632] RAX: ffffffffffffffda RBX: 0000564d0b051080 RCX: 00007fd9e133c48a
[ 318.691920] RDX: 0000564d0b051280 RSI: 0000564d0b051300 RDI: 0000564d0b0596a0
[ 318.692123] RBP: 0000000000000000 R08: 0000564d0b0512a0 R09: 0000000000000020
[ 318.692349] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564d0b0596a0
[ 318.692673] R13: 0000564d0b051280 R14: 0000000000000000 R15: 00000000ffffffff
[ 318.693007] </TASK>
[ 318.693271] Modules linked in:
[ 318.693614] CR2: 0000000000000158
[ 318.694446] ---[ end trace 0000000000000000 ]---
[ 318.694779] RIP: 0010:ni_find_attr+0x2d/0x1c0
[ 318.694952] Code: 89 ca 4d 89 c7 41 56 41 55 41 54 41 89 cc 55 48 89 fd 53 48 89 d3 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 44 24 180
[ 318.696042] RSP: 0018:ffffa6c8c0297bd8 EFLAGS: 00000246
[ 318.696531] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000080
[ 318.698114] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[ 318.699286] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[ 318.699795] R10: 0000000000000000 R11: 0000000000000005 R12: 0000000000000080
[ 318.700236] R13: ffff8d5582e68400 R14: 0000000000000100 R15: 0000000000000000
[ 318.700973] FS: 00007fd9e1c81e40(0000) GS:ffff8d55fdc00000(0000) knlGS:0000000000000000
[
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: qcom: Fix potential memory leak
Function dwc3_qcom_probe() allocates memory for resource structure
which is pointed by parent_res pointer. This memory is not
freed. This leads to memory leak. Use stack memory to prevent
memory leak.
Found by Linux Verification Center (linuxtesting.org) with SVACE. |
| In the Linux kernel, the following vulnerability has been resolved:
x86/resctrl: Clear staged_config[] before and after it is used
As a temporary storage, staged_config[] in rdt_domain should be cleared
before and after it is used. The stale value in staged_config[] could
cause an MSR access error.
Here is a reproducer on a system with 16 usable CLOSIDs for a 15-way L3
Cache (MBA should be disabled if the number of CLOSIDs for MB is less than
16.) :
mount -t resctrl resctrl -o cdp /sys/fs/resctrl
mkdir /sys/fs/resctrl/p{1..7}
umount /sys/fs/resctrl/
mount -t resctrl resctrl /sys/fs/resctrl
mkdir /sys/fs/resctrl/p{1..8}
An error occurs when creating resource group named p8:
unchecked MSR access error: WRMSR to 0xca0 (tried to write 0x00000000000007ff) at rIP: 0xffffffff82249142 (cat_wrmsr+0x32/0x60)
Call Trace:
<IRQ>
__flush_smp_call_function_queue+0x11d/0x170
__sysvec_call_function+0x24/0xd0
sysvec_call_function+0x89/0xc0
</IRQ>
<TASK>
asm_sysvec_call_function+0x16/0x20
When creating a new resource control group, hardware will be configured
by the following process:
rdtgroup_mkdir()
rdtgroup_mkdir_ctrl_mon()
rdtgroup_init_alloc()
resctrl_arch_update_domains()
resctrl_arch_update_domains() iterates and updates all resctrl_conf_type
whose have_new_ctrl is true. Since staged_config[] holds the same values as
when CDP was enabled, it will continue to update the CDP_CODE and CDP_DATA
configurations. When group p8 is created, get_config_index() called in
resctrl_arch_update_domains() will return 16 and 17 as the CLOSIDs for
CDP_CODE and CDP_DATA, which will be translated to an invalid register -
0xca0 in this scenario.
Fix it by clearing staged_config[] before and after it is used.
[reinette: re-order commit tags] |
| Cross-site request forgery vulnerability exists in LogStare Collector. If a user views a crafted page while logged, unintended operations may be performed. |
| LogStare Collector improperly handles the password hash data. An administrative user may obtain the other users' password hashes. |
