In the Linux kernel, the following vulnerability has been resolved:
cifs: validate DFS referral string offsets
parse_dfs_referrals() validates that the response header and referral
array fit in the received buffer, but each referral also contains string
offsets supplied by the server.
Those offsets are used to compute the DfsPath and NetworkAddress string
pointers without checking whether they still point inside the response
buffer. A malformed referral can therefore make the computed pointer
exceed the end of the buffer. The resulting negative max_len is then
passed to cifs_strndup_from_utf16(), and the non-Unicode path forwards it
to kst
Без оценкиEPSS 0,22%Нет опубликованного исправления
dm era: fix NULL pointer dereference in metadata_open()
In the Linux kernel, the following vulnerability has been resolved:
dm era: fix NULL pointer dereference in metadata_open()
metadata_open() returns NULL when kzalloc_obj() fails, but the
caller era_ctr() only checks IS_ERR(md). Since IS_ERR(NULL)
returns false, the NULL pointer is treated as a valid result
and later assigned to era->md, leading to a NULL pointer
dereference when the metadata is accessed.
Fix this by returning ERR_PTR(-ENOMEM) on allocation failure,
consistent with dm-cache-metadata.c, dm-thin-metadata.c, and
dm-clone-metadata.c which all use ERR_PTR(-ENOMEM) for the
same pattern.
Без оценкиEPSS 0,22%Нет опубликованного исправления
mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()
When mlxsw_sp_port_lag_index_get() fails, mlxsw_sp_port_lag_join()
returns an error without releasing the lag reference obtained by
the earlier mlxsw_sp_lag_get(). All other error paths in the
function jump to the cleanup label that ends with
mlxsw_sp_lag_put(), so this is a single missed release.
Fix the leak by replacing the bare 'return err' with a goto to the
existing error cleanup label, which will drop the reference safely.
Без оценкиEPSS 0,22%Нет опубликованного исправления
mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()
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
tipc: restrict socket queue dumps in enqueue tracepoints
In the Linux kernel, the following vulnerability has been resolved:
tipc: restrict socket queue dumps in enqueue tracepoints
tipc_sk_enqueue() runs with sk->sk_lock.slock held while the socket is
owned by user context. The spinlock protects the backlog queue in this
path, but it does not serialize against the socket owner consuming or
purging sk_receive_queue.
KASAN reported:
CPU: 14 UID: 0 PID: 1050 Comm: tipc3 Not tainted 7.1.0-rc6+ #126 PREEMPT(lazy)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x76/0xa0 lib/dump_stack.c:123
print_report+0xce/0x5b0 m
Высокий · CVSS 7.1EPSS 0,16%Нет опубликованного исправления
net: atm: reject out-of-range traffic classes in QoS validation
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 acc
net: ife: require ETH_HLEN to be pullable in ife_decode()
In the Linux kernel, the following vulnerability has been resolved:
net: ife: require ETH_HLEN to be pullable in ife_decode()
ife decode may return after making only the outer IFE header and
metadata pullable. The caller then passes the decapsulated packet to
eth_type_trans(), which expects the inner Ethernet header to be
accessible from the linear data area.
With a malformed IFE frame, the inner Ethernet header may still be
shorter than ETH_HLEN in the linear area, which can lead to a crash in
the original code.
Fix this by extending the pull check in ife_decode() so that the inner
Ethernet header is also guaranteed to be pullable before
KVM: arm64: vgic: Check the interrupt is still ours before migrating it
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic: Check the interrupt is still ours before migrating it
vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating
an interrupt to another vCPU. After reacquiring the locks it only checks
that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq))
before moving the interrupt, which assumes that an interrupt whose affinity
is preserved is still queued on this vCPU's ap_list.
That assumption no longer holds if the interrupt is taken off the ap_list
while the locks are dropped. vgic_flush_pending_lpis() removes the
interrupt from the
KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
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
Высокий · CVSS 7.1EPSS 0,19%Нет опубликованного исправления
KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Ignore pending PV EOI if the vCPU has since disabled PV EOIs
Ignore KVM's internal "service pending PV EOI" request if the vCPU has
disabled PV EOIs since the request was made. Asserting that PV EOIs are
enabled can fail if reading guest memory in pv_eoi_get_user() fails, i.e.
if pv_eoi_test_and_clr_pending() bails early, *and* the vCPU also disables
PV EOIs.
kernel BUG at arch/x86/kvm/lapic.c:3338!
Oops: invalid opcode: 0000 [#1] SMP
CPU: 4 UID: 1000 PID: 890 Comm: pv_eoi_test Not tainted 7.0.0-d585aa5894d8-vm #337 PREEMPT
Hardware name: QEMU Standard P
Высокий · CVSS 7.8EPSS 0,18%Нет опубликованного исправления
KVM: Move kvm_io_bus_get_dev() locking responsibilities to callers
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*
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: radeon: fix potential memory leak in radeonfb_pci_register()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: radeon: fix potential memory leak in radeonfb_pci_register()
The function radeonfb_pci_register() allocates memory for modelist
(by calling radeon_check_modes() which calls fb_add_videomode()).
The memory is appended to info->modelist, but is not freed in subsequent
error paths. Fix this by calling fb_destroy_modelist().
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: i740fb: fix potential memory leak in i740fb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: i740fb: fix potential memory leak in i740fb_probe()
In i740fb_probe(), the memory allocated in fb_videomode_to_modelist()
for modelist is not freed in the error paths. Fix that by calling
fb_destroy_modelist().
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: s3fb: fix potential memory leak in s3_pci_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: s3fb: fix potential memory leak in s3_pci_probe()
In s3_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()
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: uvesafb: fix potential memory leak in uvesafb_probe()
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.
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: tdfxfb: fix potential memory leak in tdfxfb_probe()
In tdfxfb_probe(), the memory allocated for modelist using
fb_videomode_to_modelist() when CONFIG_FB_3DFX_I2C is defined, is not
freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist().
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: carminefb: fix potential memory leak in alloc_carmine_fb()
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()
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: nvidia: fix potential memory leak in nvidiafb_probe()
In the Linux kernel, the following vulnerability has been resolved:
fbdev: nvidia: fix potential memory leak in nvidiafb_probe()
In nvidiafb_probe(), the memory allocated for modelist in
nvidia_set_fbinfo() is not freed in the subsequent error paths.
Fix that by calling fb_destroy_modelist().
Без оценкиEPSS 0,22%Нет опубликованного исправления
fbdev: tridentfb: fix potential memory leak in trident_pci_probe()
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().
Без оценкиEPSS 0,22%Нет опубликованного исправления
netfilter: xt_cluster: reject template conntracks in hash match
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xt_cluster: reject template conntracks in hash match
xt_cluster_mt() treats any non-NULL nf_ct_get() result as a fully
initialized conntrack and passes it to xt_cluster_hash().
This causes a state confusion bug when the raw table CT target attaches
a template conntrack to skb->_nfct before normal conntrack processing.
Templates carry IPS_TEMPLATE status but do not have a valid tuple for
hashing yet, so xt_cluster_hash() can hit its WARN_ON() path on the
zeroed l3num field.
Reject template conntracks before hashing them. This matches existing
netfilter handling