| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: do not index invalid pin_assignments
A poorly implemented DisplayPort Alt Mode port partner can indicate
that its pin assignment capabilities are greater than the maximum
value, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_show
will cause a BRK exception due to an out of bounds array access.
Prevent for loop in pin_assignment_show from accessing
invalid values in pin_assignments by adding DP_PIN_ASSIGN_MAX
value in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loop
condition. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()
vgic_v2_parse_attr() is responsible for finding the vCPU that matches
the user-provided CPUID, which (of course) may not be valid. If the ID
is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled
gracefully.
Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()
actually returns something and fail the ioctl if not. |
| In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: avoid off-by-one read from userspace
We try to access count + 1 byte from userspace with memdup_user(buffer,
count + 1). However, the userspace only provides buffer of count bytes and
only these count bytes are verified to be okay to access. To ensure the
copied buffer is NUL terminated, we use memdup_user_nul instead. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate the parameters of bo mapping operations more clearly
Verify the parameters of
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring: drop any code related to SCM_RIGHTS
This is dead code after we dropped support for passing io_uring fds
over SCM_RIGHTS, get rid of it. |
| In the Linux kernel, the following vulnerability has been resolved:
binder: check offset alignment in binder_get_object()
Commit 6d98eb95b450 ("binder: avoid potential data leakage when copying
txn") introduced changes to how binder objects are copied. In doing so,
it unintentionally removed an offset alignment check done through calls
to binder_alloc_copy_from_buffer() -> check_buffer().
These calls were replaced in binder_get_object() with copy_from_user(),
so now an explicit offset alignment check is needed here. This avoids
later complications when unwinding the objects gets harder.
It is worth noting this check existed prior to commit 7a67a39320df
("binder: add function to copy binder object from buffer"), likely
removed due to redundancy at the time. |
| In the Linux kernel, the following vulnerability has been resolved:
platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks
After retrieving WMI data blocks in sysfs callbacks, check for the
validity of them before dereferencing their content. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
When processing the last block, the s390 ctr code will always read
a whole block, even if there isn't a whole block of data left. Fix
this by using the actual length left and copy it into a buffer first
for processing. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Flush pages under kvm->lock to fix UAF in svm_register_enc_region()
Do the cache flush of converted pages in svm_register_enc_region() before
dropping kvm->lock to fix use-after-free issues where region and/or its
array of pages could be freed by a different task, e.g. if userspace has
__unregister_enc_region_locked() already queued up for the region.
Note, the "obvious" alternative of using local variables doesn't fully
resolve the bug, as region->pages is also dynamically allocated. I.e. the
region structure itself would be fine, but region->pages could be freed.
Flushing multiple pages under kvm->lock is unfortunate, but the entire
flow is a rare slow path, and the manual flush is only needed on CPUs that
lack coherency for encrypted memory. |
| In the Linux kernel, the following vulnerability has been resolved:
NFC: nci: uart: Set tty->disc_data only in success path
Setting tty->disc_data before opening the NCI device means we need to
clean it up on error paths. This also opens some short window if device
starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded
(broken hardware?). Close the window by exposing tty->disc_data only on
the success path, when opening of the NCI device and try_module_get()
succeeds.
The code differs in error path in one aspect: tty->disc_data won't be
ever assigned thus NULL-ified. This however should not be relevant
difference, because of "tty->disc_data=NULL" in nci_uart_tty_open(). |
| In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Release rproc->clean_table after rproc_attach() fails
When rproc->state = RPROC_DETACHED is attached to remote processor
through rproc_attach(), if rproc_handle_resources() returns failure,
then the clean table should be released, otherwise the following
memory leak will occur.
unreferenced object 0xffff000086a99800 (size 1024):
comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)
hex dump (first 32 bytes):
00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............
00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............
backtrace:
[<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc
[<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230
[<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260
[<0000000037818dae>] kmemdup+0x34/0x60
[<00000000610f7f57>] rproc_boot+0x35c/0x56c
[<0000000065f8871a>] rproc_add+0x124/0x17c
[<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4
[<000000003bcaa37d>] platform_probe+0x68/0xd8
[<00000000771577f9>] really_probe+0x110/0x27c
[<00000000531fea59>] __driver_probe_device+0x78/0x12c
[<0000000080036a04>] driver_probe_device+0x3c/0x118
[<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8
[<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4
[<000000001a53b53e>] __device_attach+0xfc/0x18c
[<00000000d1a2a32c>] device_initial_probe+0x14/0x20
[<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4
unreferenced object 0xffff0000864c9690 (size 16): |
| In the Linux kernel, the following vulnerability has been resolved:
remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()
When rproc->state = RPROC_DETACHED and rproc_attach() is used
to attach to the remote processor, if rproc_handle_resources()
returns a failure, the resources allocated by imx_rproc_prepare()
should be released, otherwise the following memory leak will occur.
Since almost the same thing is done in imx_rproc_prepare() and
rproc_resource_cleanup(), Function rproc_resource_cleanup() is able
to deal with empty lists so it is better to fix the "goto" statements
in rproc_attach(). replace the "unprepare_device" goto statement with
"clean_up_resources" and get rid of the "unprepare_device" label.
unreferenced object 0xffff0000861c5d00 (size 128):
comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............
backtrace:
[<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c
[<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0
[<00000000521c0345>] kmalloc_trace+0x40/0x158
[<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8
[<000000002815755e>] imx_rproc_prepare+0xe0/0x180
[<0000000003f61b4e>] rproc_boot+0x2ec/0x528
[<00000000e7e994ac>] rproc_add+0x124/0x17c
[<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4
[<00000000efc298a1>] platform_probe+0x68/0xd8
[<00000000110be6fe>] really_probe+0x110/0x27c
[<00000000e245c0ae>] __driver_probe_device+0x78/0x12c
[<00000000f61f6f5e>] driver_probe_device+0x3c/0x118
[<00000000a7874938>] __device_attach_driver+0xb8/0xf8
[<0000000065319e69>] bus_for_each_drv+0x84/0xe4
[<00000000db3eb243>] __device_attach+0xfc/0x18c
[<0000000072e4e1a4>] device_initial_probe+0x14/0x20 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: do not ping device which has failed to load firmware
Syzkaller reports [1, 2] crashes caused by an attempts to ping
the device which has failed to load firmware. Since such a device
doesn't pass 'ieee80211_register_hw()', an internal workqueue
managed by 'ieee80211_queue_work()' is not yet created and an
attempt to queue work on it causes null-ptr-deref.
[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff
[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 |
| In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()
It seems that if userspace provides a correct IFA_TARGET_NETNSID value
but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()
returns -EINVAL with an elevated "struct net" refcount. |
| In the Linux kernel, the following vulnerability has been resolved:
net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devices
Maximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kb
and 64 Kb respectively. Adjust max size definitions and return correct
EEPROM length based on device. Also prevent out-of-bound read/write. |
| In the Linux kernel, the following vulnerability has been resolved:
perf: Fix sample vs do_exit()
Baisheng Gao reported an ARM64 crash, which Mark decoded as being a
synchronous external abort -- most likely due to trying to access
MMIO in bad ways.
The crash further shows perf trying to do a user stack sample while in
exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address
space it is trying to access.
It turns out that we stop perf after we tear down the userspace mm; a
receipie for disaster, since perf likes to access userspace for
various reasons.
Flip this order by moving up where we stop perf in do_exit().
Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER
to abort when the current task does not have an mm (exit_mm() makes
sure to set current->mm = NULL; before commencing with the actual
teardown). Such that CPU wide events don't trip on this same problem. |
| In the Linux kernel, the following vulnerability has been resolved:
ubifs: Set page uptodate in the correct place
Page cache reads are lockless, so setting the freshly allocated page
uptodate before we've overwritten it with the data it's supposed to have
in it will allow a simultaneous reader to see old data. Move the call
to SetPageUptodate into ubifs_write_end(), which is after we copied the
new data into the page. |
| In the Linux kernel, the following vulnerability has been resolved:
net: ll_temac: platform_get_resource replaced by wrong function
The function platform_get_resource was replaced with
devm_platform_ioremap_resource_byname and is called using 0 as name.
This eventually ends up in platform_get_resource_byname in the call
stack, where it causes a null pointer in strcmp.
if (type == resource_type(r) && !strcmp(r->name, name))
It should have been replaced with devm_platform_ioremap_resource. |
| In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 ("pipe: Add general notification queue support") a
regression was introduced that would lock up resized pipes under certain
conditions. See the reproducer in [1].
The commit resizing the pipe ring size was moved to a different
function, doing that moved the wakeup for pipe->wr_wait before actually
raising pipe->max_usage. If a pipe was full before the resize occured it
would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a
watch queue.
[Christian Brauner <brauner@kernel.org>: rewrite to account for watch queues] |
| In the Linux kernel, the following vulnerability has been resolved:
Input: ims-pcu - check record size in ims_pcu_flash_firmware()
The "len" variable comes from the firmware and we generally do
trust firmware, but it's always better to double check. If the "len"
is too large it could result in memory corruption when we do
"memcpy(fragment->data, rec->data, len);" |
