| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()
When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs,
the error rollback loop does not correctly revert the preceding
replacements. The loop decrements the index but fails to update the
vr pointer, which still points to the VR that caused the failure. As
a result, the condition and the rollback call always operate on the
same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple
times on it while never rolling back the earlier VRs. Those VRs
continue to hold a reference to new_tree acquired via
mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree.
Fix by reinitializing vr inside the error loop with the updated index:
vr = &mlxsw_sp->router->vrs[i];
so that the loop correctly iterates over all VRs that were actually
replaced. |
| In the Linux kernel, the following vulnerability has been resolved:
vduse: Fix race in vduse_dev_msg_sync and vduse_dev_read_iter
There is one race case in vduse_dev_msg_sync and vduse_dev_read_iter:
vduse_dev_read_iter():
lock(msg_lock);
dequeue_msg(send_list);
unlock(msg_lock);
vduse_dev_msg_sync():
wait_timeout() finish
lock(msg_lock);
check msg->complete is false
list_del(msg); <- double list_del() crash!
To fix this case, we shall ensure vduse_msg is on send_list or recv_list
outside the msg_lock critical section. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc4-control: Fix TOCTOU in sof_ipc4_bytes_put
In sof_ipc4_bytes_put(), the copy size is derived from the old
data->size in the buffer rather than the incoming new data's size
field from ucontrol. If the new data has a different size, the copy
uses the wrong length: it may truncate valid data or copy stale bytes.
Fix by validating and using the incoming data's sof_abi_hdr.size from
ucontrol before copying. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc4-control: Validate notification payload size
Validate MODULE_NOTIFICATION payload length before reading
bytes/channel data in control update handling. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: ipc3-control: Fix TOCTOU in bytes_put and bytes_get
In sof_ipc3_bytes_put(), the size used for the memcpy is derived from
the old data->size already in the buffer, not the incoming new data's
size field. If the new data has a different size, the copy length is
wrong: it may truncate valid data or copy stale bytes.
Similarly, sof_ipc3_bytes_get() checks data->size against max_size
without accounting for the sizeof(struct sof_ipc_ctrl_data) offset
of the flex array within the allocation.
Fix bytes_put to validate and use the incoming data's sof_abi_hdr.size
from ucontrol before copying. Fix bytes_get to subtract sizeof(*cdata)
from the bounds check to match the actual available space. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: topology: validate vendor array size before parsing
sof_parse_token_sets() reads array->size while iterating over topology
private data. The loop condition only checks that some data remains, so a
malformed topology with a truncated trailing vendor array can make the
parser read the size field before a full vendor-array header is available.
Validate that the remaining private data contains a complete
snd_soc_tplg_vendor_array header before reading array->size.
The declared array size check also needs to remain signed. asize is an int,
but sizeof(*array) has type size_t, so comparing them directly promotes
negative asize values to unsigned and lets them pass the check,
as reported in the stable review thread reference below.
Cast sizeof(*array) to int when validating the declared array size. This
rejects negative, zero and otherwise too-small sizes before the parser
dispatches to the tuple-specific code. |
| In the Linux kernel, the following vulnerability has been resolved:
net: atm: reject out-of-range traffic classes in QoS validation
Reject ATM traffic classes above ATM_ANYCLASS in check_tp().
SO_ATMQOS stores the supplied QoS after check_qos() succeeds, so
accepting larger values leaves invalid traffic_class values in
vcc->qos.
That bad state later reaches pvc_info(), which indexes class_name[]
with vcc->qos.{rx,tp}.traffic_class. Values above ATM_ANYCLASS cause
an out-of-bounds read when /proc/net/atm/pvc is read.
Tighten the existing QoS validation so invalid traffic_class values
are rejected at the point where user supplied QoS is accepted. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: Add missing radix_tree_preload() in _gaccess_shadow_fault()
Add missing radix_tree_preload() in _gaccess_shadow_fault() to
guarantee forward progress. The core of _gaccess_shadow_fault() has
been split into ___gaccess_shadow_fault() in order to simplify locking. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: Fix unlikely race in try_get_locked_pte()
Fix an unlikely race in try_get_locked_pte(), which could have happened
if puds or pmds get unmapped between the p?dp_get() and p?d_offset()
functions. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: pci: Fix GISC refcount leak on AIF enable failure
kvm_s390_gisc_register() registers the guest ISC before pinning
the guest interrupt forwarding pages and allocating the AISB bit.
If any of the later setup steps fails, the function unwinds the
pinned pages and other local state, but does not unregister the
GISC reference. Add the missing kvm_s390_gisc_unregister() to the
error unwind path. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
Hyunwoo Kim reports some really bad races should the following
situation occur:
- LPI-I is pending in vcpu-B's AP list
- vcpu-A writes to vcpu-B's RD to disable its LPIs
- vcpu-C moves I from B to C
If the last two race nicely enough, vgic_prune_ap_list() can drop
the irq and AP list locks, reacquire them, and in the interval
the irq has been freed. UAF follows.
The fix is two-fold:
- Before dropping the irq and ap_list locks, take a reference on
the irq
- Do not try to handle migration of the pending bit: there is no
expectation that this state is retained, as per the architecture
With that, we're sure that the interrupt is still around, and we
safely remove it from the AP list as it has no target at this
stage (unless another interrupt fires, but that's another story). |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: TDX: Reject concurrent change to CPUID entry count
Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the
initial read and the subsequent copy of the initialization data.
tdx_td_init() first reads user_data->cpuid.nent to size the flexible
kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent,
and that field can differ from the value used to size the allocation if
userspace modifies the input concurrently. setup_tdparams_cpuids() later
passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as
the array bound for the copied entries.
Require the copied count to match the value used to size the allocation
so that CPUID parsing cannot access beyond the entries actually copied. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Nullify irqfd->producer if updating IRTE for bypass fails
Nullify irqfd->producer if updating the IRTE for bypass fails, as leaving a
dangling pointer will result in a use-after-free if the irqfd is reachable
through KVM's routing, but the producer is freed separately. E.g. for VFIO
PCI, the producer is embedded in struct "vfio_pci_irq_ctx" and freed when
the vector is disabled, which can happen independent of routing updates.
[sean: drop PPC change, massage changelog] |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
kvm_io_bus_get_dev() returns a device that is only matched by the
address, and nothing else. This can cause a lifetime issue if
the matched device is not the expected type, as by the time
the caller can introspect the object, it might be gone (the srcu
lock having been dropped).
Given that there is only a single user of this helper, the simplest
option is to move the locking responsibility to the caller, which
can keep the srcu lock held for as long as it wants.
Note that this aligns with other kvm_io_bus*() helpers, which
already require the srcu lock to be held by the callers. |
| In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: account pKVM reclaim against the VM mm
Protected guest faults charge long term pins to the VM's mm. Teardown
can run later from file release, where current->mm may be unrelated.
Drop the charge from kvm->mm instead. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: metronomefb: fix potential memory leak in metronomefb_probe()
The memory allocated for pagerefs in fb_deferred_io_init() is not freed
on the error path. Fix it by calling fb_deferred_io_cleanup(). |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: uvesafb: fix potential memory leak in uvesafb_probe()
Due to an incorrect goto label, memory allocated for modedb and modelist
in uvesafb_vbe_init() is not freed in some error paths. Fix this by
updating the goto label. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()
The memory allocated for modelist in fb_videomode_to_modelist() is not
freed in the subsequent error path.
Fix that by calling fb_destroy_modelist() |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: vesafb: fix memory leak in vesafb_probe()
Since commit 73ce73c30ba9 ("fbdev: Transfer video= option strings to
caller; clarify ownership") the string returned from fb_get_options()
is expected to be freed by the caller. But the string is not freed in
vesafb_probe(). Fix that by freeing the option string after setup. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: tridentfb: fix potential memory leak in trident_pci_probe()
In trident_pci_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() is not freed in subsequent error paths.
Fix that by calling fb_destroy_modelist(). |
