| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unauthenticated attackers can rename arbitrary devices of arbitrary users (i.e., EV chargers). |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq
storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it
doesn't need to make forward progress under memory pressure. Marking this
workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a
non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following
warning:
[ 14.506347] ------------[ cut here ]------------
[ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn
[ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130
[ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu
[ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022
[ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun
[ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130
<-snip->
[ 14.506408] Call Trace:
[ 14.506412] __flush_work+0xf1/0x1c0
[ 14.506414] __cancel_work_timer+0x12f/0x1b0
[ 14.506417] ? kernfs_put+0xf0/0x190
[ 14.506418] cancel_delayed_work_sync+0x13/0x20
[ 14.506420] disk_block_events+0x78/0x80
[ 14.506421] del_gendisk+0x3d/0x2f0
[ 14.506423] sr_remove+0x28/0x70
[ 14.506427] device_release_driver_internal+0xef/0x1c0
[ 14.506428] device_release_driver+0x12/0x20
[ 14.506429] bus_remove_device+0xe1/0x150
[ 14.506431] device_del+0x167/0x380
[ 14.506432] __scsi_remove_device+0x11d/0x150
[ 14.506433] scsi_remove_device+0x26/0x40
[ 14.506434] storvsc_remove_lun+0x40/0x60
[ 14.506436] process_one_work+0x209/0x400
[ 14.506437] worker_thread+0x34/0x400
[ 14.506439] kthread+0x121/0x140
[ 14.506440] ? process_one_work+0x400/0x400
[ 14.506441] ? kthread_park+0x90/0x90
[ 14.506443] ret_from_fork+0x35/0x40
[ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- |
| Unauthenticated attackers can rename "rooms" of arbitrary users. |
| An unauthenticated attacker can delete any user's "rooms" by knowing the user's and room IDs. |
| In the Linux kernel, the following vulnerability has been resolved:
md: call __md_stop_writes in md_stop
From the link [1], we can see raid1d was running even after the path
raid_dtr -> md_stop -> __md_stop.
Let's stop write first in destructor to align with normal md-raid to
fix the KASAN issue.
[1]. https://lore.kernel.org/linux-raid/CAPhsuW5gc4AakdGNdF8ubpezAuDLFOYUO_sfMZcec6hQFm8nhg@mail.gmail.com/T/#m7f12bf90481c02c6d2da68c64aeed4779b7df74a |
| In the Linux kernel, the following vulnerability has been resolved:
xen/privcmd: fix error exit of privcmd_ioctl_dm_op()
The error exit of privcmd_ioctl_dm_op() is calling unlock_pages()
potentially with pages being NULL, leading to a NULL dereference.
Additionally lock_pages() doesn't check for pin_user_pages_fast()
having been completely successful, resulting in potentially not
locking all pages into memory. This could result in sporadic failures
when using the related memory in user mode.
Fix all of that by calling unlock_pages() always with the real number
of pinned pages, which will be zero in case pages being NULL, and by
checking the number of pages pinned by pin_user_pages_fast() matching
the expected number of pages. |
| An unauthenticated attacker can obtain EV charger version and firmware upgrading history by knowing the charger ID. |
| Unauthenticated attackers can query an API endpoint and get device details. |
| An unauthenticated attackers can obtain a list of smart devices by knowing a valid username through an unprotected API. |
| In the Linux kernel, the following vulnerability has been resolved:
s390: fix double free of GS and RI CBs on fork() failure
The pointers for guarded storage and runtime instrumentation control
blocks are stored in the thread_struct of the associated task. These
pointers are initially copied on fork() via arch_dup_task_struct()
and then cleared via copy_thread() before fork() returns. If fork()
happens to fail after the initial task dup and before copy_thread(),
the newly allocated task and associated thread_struct memory are
freed via free_task() -> arch_release_task_struct(). This results in
a double free of the guarded storage and runtime info structs
because the fields in the failed task still refer to memory
associated with the source task.
This problem can manifest as a BUG_ON() in set_freepointer() (with
CONFIG_SLAB_FREELIST_HARDENED enabled) or KASAN splat (if enabled)
when running trinity syscall fuzz tests on s390x. To avoid this
problem, clear the associated pointer fields in
arch_dup_task_struct() immediately after the new task is copied.
Note that the RI flag is still cleared in copy_thread() because it
resides in thread stack memory and that is where stack info is
copied. |
| Unauthenticated attackers can retrieve full list of users associated with arbitrary accounts. |
| Unauthenticated attackers can retrieve serial number of smart meters associated to a specific user account. |
| An attacker can upload an arbitrary file instead of a plant image. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/mprotect: only reference swap pfn page if type match
Yu Zhao reported a bug after the commit "mm/swap: Add swp_offset_pfn() to
fetch PFN from swap entry" added a check in swp_offset_pfn() for swap type [1]:
kernel BUG at include/linux/swapops.h:117!
CPU: 46 PID: 5245 Comm: EventManager_De Tainted: G S O L 6.0.0-dbg-DEV #2
RIP: 0010:pfn_swap_entry_to_page+0x72/0xf0
Code: c6 48 8b 36 48 83 fe ff 74 53 48 01 d1 48 83 c1 08 48 8b 09 f6
c1 01 75 7b 66 90 48 89 c1 48 8b 09 f6 c1 01 74 74 5d c3 eb 9e <0f> 0b
48 ba ff ff ff ff 03 00 00 00 eb ae a9 ff 0f 00 00 75 13 48
RSP: 0018:ffffa59e73fabb80 EFLAGS: 00010282
RAX: 00000000ffffffe8 RBX: 0c00000000000000 RCX: ffffcd5440000000
RDX: 1ffffffffff7a80a RSI: 0000000000000000 RDI: 0c0000000000042b
RBP: ffffa59e73fabb80 R08: ffff9965ca6e8bb8 R09: 0000000000000000
R10: ffffffffa5a2f62d R11: 0000030b372e9fff R12: ffff997b79db5738
R13: 000000000000042b R14: 0c0000000000042b R15: 1ffffffffff7a80a
FS: 00007f549d1bb700(0000) GS:ffff99d3cf680000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000440d035b3180 CR3: 0000002243176004 CR4: 00000000003706e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
change_pte_range+0x36e/0x880
change_p4d_range+0x2e8/0x670
change_protection_range+0x14e/0x2c0
mprotect_fixup+0x1ee/0x330
do_mprotect_pkey+0x34c/0x440
__x64_sys_mprotect+0x1d/0x30
It triggers because pfn_swap_entry_to_page() could be called upon e.g. a
genuine swap entry.
Fix it by only calling it when it's a write migration entry where the page*
is used.
[1] https://lore.kernel.org/lkml/CAOUHufaVC2Za-p8m0aiHw6YkheDcrO-C3wRGixwDS32VTS+k1w@mail.gmail.com/ |
| Unauthenticated attackers can send configuration settings to device and possible perform physical actions remotely (e.g., on/off). |
| Unauthenticated attackers can query information about total energy consumed by EV chargers of arbitrary users. |
| In the Linux kernel, the following vulnerability has been resolved:
bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem
The vmemmap pages is marked by kmemleak when allocated from memblock.
Remove it from kmemleak when freeing the page. Otherwise, when we reuse
the page, kmemleak may report such an error and then stop working.
kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing)
kmemleak: Kernel memory leak detector disabled
kmemleak: Object 0xffff98fb6be00000 (size 335544320):
kmemleak: comm "swapper", pid 0, jiffies 4294892296
kmemleak: min_count = 0
kmemleak: count = 0
kmemleak: flags = 0x1
kmemleak: checksum = 0
kmemleak: backtrace: |
| In the Linux kernel, the following vulnerability has been resolved:
writeback: avoid use-after-free after removing device
When a disk is removed, bdi_unregister gets called to stop further
writeback and wait for associated delayed work to complete. However,
wb_inode_writeback_end() may schedule bandwidth estimation dwork after
this has completed, which can result in the timer attempting to access the
just freed bdi_writeback.
Fix this by checking if the bdi_writeback is alive, similar to when
scheduling writeback work.
Since this requires wb->work_lock, and wb_inode_writeback_end() may get
called from interrupt, switch wb->work_lock to an irqsafe lock. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix possible memory leak in btrfs_get_dev_args_from_path()
In btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if
the path is invalid. In this case, btrfs_get_dev_args_from_path()
returns directly without freeing args->uuid and args->fsid allocated
before, which causes memory leak.
To fix these possible leaks, when btrfs_get_bdev_and_sb() fails,
btrfs_put_dev_args_from_path() is called to clean up the memory. |
| In the Linux kernel, the following vulnerability has been resolved:
kcm: fix strp_init() order and cleanup
strp_init() is called just a few lines above this csk->sk_user_data
check, it also initializes strp->work etc., therefore, it is
unnecessary to call strp_done() to cancel the freshly initialized
work.
And if sk_user_data is already used by KCM, psock->strp should not be
touched, particularly strp->work state, so we need to move strp_init()
after the csk->sk_user_data check.
This also makes a lockdep warning reported by syzbot go away. |
