PatchFirst · Vulnérabilités récentes
Vulnérabilités publiées pour linux-fips au cours des 30 derniers jours : 321. Présentes dans le catalogue KEV : 0.
Vulnérabilités : 5693
In the Linux kernel, the following vulnerability has been resolved: i2c: mux: Fix channel node leak on adapter add failure i2c_mux_add_adapter() takes a reference to the Device Tree channel node before registering the new adapter. If adapter registration fails, the error path frees the private data without dropping that reference. Release the channel node before freeing the private data.
In the Linux kernel, the following vulnerability has been resolved: ALSA: pcm: Fix race between non-atomic ops and trigger-start We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hw_params, hw_free and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hw_params & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HW_PARAMS for the already prepared stream, while another thread B triggers the PCM start in the
In the Linux kernel, the following vulnerability has been resolved: nvdimm/btt: reject an arena whose nfree is below the lane count The BTT info block's nfree field, the number of reserve free blocks, is read from the medium without validation. btt_freelist_init() and btt_rtt_init() size the per-lane freelist[] and rtt[] arrays by nfree, but the I/O path indexes them by the lane from nd_region_acquire_lane(), which is bounded by nd_region->num_lanes (ND_MAX_LANES), not by nfree. A crafted or foreign arena whose nfree is below the lane count makes freelist[lane]/rtt[lane] run past the allocation: an out-of-bounds write. btt.rst documents t
In the Linux kernel, the following vulnerability has been resolved: parisc: eisa: Fix infinite loop when parsing invalid IRQ value When an invalid value is passed via the "eisa_irq_edge=" kernel command line parameter (e.g. "eisa_irq_edge=16,5"), eisa_irq_setup() prints an error message and continues without advancing the current position. As a result the same invalid value is parsed again and again, causing an infinite loop while the kernel boots. Advance to the next comma-separated entry, or stop parsing when there is no next entry, before continuing so that the remaining entries are processed normally.
In the Linux kernel, the following vulnerability has been resolved: mtd: mtdoops: free page bitmap when the backing MTD is removed mtdoops_notify_add() allocates oops_page_used when the configured MTD device is registered. mtdoops_notify_remove() detaches from that device but leaves the bitmap allocated. If the same MTD device is later registered again, the add path allocates a new bitmap and overwrites the old pointer, leaking one vmalloc allocation per remove/add cycle. This is only visible when the backing MTD device can disappear and be registered again while mtdoops remains loaded, so the usual static MTD case does not expose it. F
In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: validate ONFI extended parameter page sections nand_flash_detect_ext_param_page() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation. Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfi_ext_ecc_info. Use device-scoped dia
In the Linux kernel, the following vulnerability has been resolved: batman-adv: fix stale receive device on merged fragments Fragment reassembly reuses the skb from the highest-numbered buffered fragment as the merged packet. When that fragment was received on a hard interface which is deleted before the chain completes, the merged skb can re-enter the receive path with a stale skb->dev and skb_iif. batadv_batman_skb_recv() passes such merged packets through the normal receive handlers again. DAT and bridge loop avoidance both derive the ARP header length from skb->dev, so they can dereference the freed net_device before the packet reaches
In the Linux kernel, the following vulnerability has been resolved: batman-adv: dat: avoid unaligned fault in IP extraction Independent of the alignment of the ARP packet in the SKB, either the batadv_arp_ip_src or the batadv_arp_ip_dst will have an unaligned access (on HW without native unaligned read support). Use get_unaligned() to handle this properly on all architectures.
In the Linux kernel, the following vulnerability has been resolved: batman-adv: bla: fix freeing of claims on meshif deletion When the mesh interface is getting deleted, then batadv_bla_del_backbone_claims() (via batadv_bla_purge_backbone_gw()) could make sure that all claims gets removed. But this function is only executed when bat_priv->bla.claim_hash is not NULL. And since batadv_bla_free() is always setting it to NULL before it is (indirectly) called, it was never actually executed. But the batadv_bla_purge_claims() -> batadv_handle_unclaim() is at the moment too fragile because the BLA code is not handling the rehashing in batadv_bla_
In the Linux kernel, the following vulnerability has been resolved: iio: dac: m62332: Fix regulator reference count imbalance m62332_set_value() enables the Vcc regulator on every write of a non-zero value and disables it on every write of zero, without tracking the channel's current state. Because the regulator is reference counted, changing a channel directly from one non-zero value to another enables it more than once, while a later write of zero disables it only once. The reference count never returns to zero and the regulator is left enabled indefinitely. Only enable the regulator on the transition from zero to non-zero, and only disa
In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always flush vpid02 on first use Make sure vpid02 is always flushed on first use by setting last_vpid=0 when allocating vpid02. nested_vmx_transition_tlb_flush() will always detect a VPID change on first VM-Enter after VMXON, because VPID=0 in vmcs12 is not allowed if L1 enables VPID. This avoids using stale TLB entries from a previous lifetime of the VPID, that might have been associated with a different vCPU (or a completely different VM). Note that last_vpid is already being initialized as 0 when the vCPU is created, but it is not reset when vpid02 is freed
In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Service local TLB flushes on failed nested VM-Enter KVM services local TLB flushes on "full" nested VM-Exits (through __nested_vmx_vmexit()), but not if a nested VM-Enter fails (e.g. due to failed VMCS checks in nested_vmx_enter_non_root_mode()). However, it is possible that KVM had queued TLB flushes that need to be performed, even if the nested VM-Enter was not successful. For example, if VPID is disabled for L2 (via nested_vmx_transition_tlb_flush(), or if via the MSR load lists, as the SDM says: If any MSR is being loaded in such a way that would architec
In the Linux kernel, the following vulnerability has been resolved: KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on. For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: hyper-v: Clamp stimer deadline to avoid livelock Fix an issue where userspace or the guest can program an Hyper-V synthetic timer to have a deadline in the past via integer overflow, preventing the CPU from making progress and triggering an RCU stall. Hyper-V's SynIC exposes 4 per-vCPU synthetic timers to the guest, which are emulated by KVM. Each is programmed through the HV_X64_MSR_STIMERi_CONFIG and HV_X64_MSR_STIMERi_COUNT MSRs. Depending on CONFIG, COUNT represents either the absolute expiration time or the period of a periodic timer, both expressed in 100ns
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix length check __import_wp_info() struct kvm_hw_breakpoint::len is a __u64 that is fully controlled by user space. This is then assigned to wp_info->len, which is an int. The bounds check is done on the truncated value while the allocation uses the untruncated one: wp_info->len = bp_data->len; [...] if (wp_info->len < 0 || wp_info->len > MAX_WP_SIZE) return -EINVAL; wp_info->old_data = kmalloc(bp_data->len, GFP_KERNEL_ACCOUNT); Use the validated value for the allocation as intended. Without this fix userspace can trigger >4GB allocations which will fai
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix memory leak in guest debug handling bp_data is freed only for the error case by kfree(bp_data). Every successful KVM_SET_GUEST_DEBUG will leak bp_data.
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Fix old_data leak in guest debug error path __import_wp_info() allocates a per-watchpoint old_data buffer to back up the original guest memory contents. If a later watchpoint of the same KVM_SET_GUEST_DEBUG request fails to import, kvm_s390_import_bp_data() jumps to the error label, which frees the wp_info array but not the old_data buffers of the entries that were imported successfully. Up to MAX_BP_COUNT - 1 buffers of up to MAX_WP_SIZE bytes are leaked per failed request, and the request can be repeated. Create error handling for cleaning up all created old_d
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Free guest debug data on vcpu destroy kvm_s390_clear_bp_data() is only called from kvm_arch_vcpu_ioctl_set_guest_debug(), i.e. when user space changes or disables debugging. A vCPU that is destroyed while hardware breakpoints are still armed - the normal case when the VMM just exits or crashes - leaks hw_bp_info, hw_wp_info and all old_data buffers, since generic KVM frees the vCPU right after kvm_arch_vcpu_destroy(). That is bounded by MAX_BP_COUNT entries, so roughly 8 KiB per vCPU, but it is unbounded over VM lifetimes. The allocations are GFP_KERNEL_ACCOUNT,
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Take srcu when importing watchpoint data __import_wp_info() backs up the original guest memory contents of a watchpoint with read_guest_abs(), which is kvm_read_guest() and therefore resolves the memslot via __kvm_memslots(). That requires kvm->srcu (or kvm->slots_lock) to be held, otherwise a concurrent memslot update can free the memslots array under us once its SRCU grace period has elapsed. As this is not fast path, following lock ordering (mutex first, then srcu) take the big hammer and hold the srcu for the full import.
In the Linux kernel, the following vulnerability has been resolved: KVM: s390: Zero initialize data structures for inject_pfault_token __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values. Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data. Fix by zero-initializing the irq struct. Do the same for the inti data structure.
Comparez votre pile et les versions installées aux bases de vulnérabilités actuelles.