Уязвимости linux-riscv-5.15 · Страница 117

KVM: s390: pci: Fix GISC refcount leak on AIF enable failure

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.

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

• Обновитесь до 5.15.0-1111.115~20.04.1

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

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

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*

• Обновитесь до 5.15.0-1111.115~20.04.1

fbdev: metronomefb: fix potential memory leak in metronomefb_probe()

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().

• Обновитесь до 5.15.0-1111.115~20.04.1

fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_probe()

In the Linux kernel, the following vulnerability has been resolved: fbdev: broadsheetfb: fix potential memory leak in broadsheetfb_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().

• Обновитесь до 5.15.0-1111.115~20.04.1

fbdev: hecubafb: fix potential memory leak in hecubafb_probe()

In the Linux kernel, the following vulnerability has been resolved: fbdev: hecubafb: fix potential memory leak in hecubafb_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().

• Обновитесь до 5.15.0-1111.115~20.04.1

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().

• Обновитесь до 5.15.0-1111.115~20.04.1

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().

• Обновитесь до 5.15.0-1111.115~20.04.1

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()

• Обновитесь до 5.15.0-1111.115~20.04.1

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.

• Обновитесь до 5.15.0-1111.115~20.04.1

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().

• Обновитесь до 5.15.0-1111.115~20.04.1

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()

• Обновитесь до 5.15.0-1111.115~20.04.1

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().

• Обновитесь до 5.15.0-1111.115~20.04.1

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().

• Обновитесь до 5.15.0-1111.115~20.04.1

ASoC: mediatek: mt8192: Check runtime resume during probe

In the Linux kernel, the following vulnerability has been resolved: ASoC: mediatek: mt8192: Check runtime resume during probe The MT8192 AFE probe enables runtime PM temporarily while reinitializing the regmap cache from hardware, but it uses pm_runtime_get_sync() without checking the return value. If runtime resume fails, probe keeps going without the device necessarily being accessible, and pm_runtime_get_sync() may leave the PM usage count incremented. The regmap_reinit_cache() failure path also returns before dropping the temporary PM reference and before clearing pm_runtime_bypass_reg_ctl. Use pm_runtime_resume_and_get() so resume fa

• Обновитесь до 5.15.0-1113.117~20.04.2

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

• Обновитесь до 5.15.0-1111.115~20.04.1

netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_queue: pin bridge device while NFQUEUE holds fake dst The br_netfilter fake rtable is embedded in struct net_bridge and is attached to bridged packets with skb_dst_set_noref(). If such a packet is queued to NFQUEUE, __nf_queue() upgrades that fake dst with skb_dst_force(). At that point the queued skb can hold a real dst reference after bridge teardown has started. The problem is not that every bridged packet needs its own dst reference. The problem is that NFQUEUE can keep the bridge private fake dst alive after unregister begins. Fix this by keeping the br

• Обновитесь до 5.15.0-1113.117~20.04.2

netfilter: nf_conntrack_sip: validate skb_dst() before accessing it

In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conntrack_sip: validate skb_dst() before accessing it tc ingress and openvswitch do not guarantee routing information to be available. These subsystems use the conntrack helper infrastructure, and the SIP helper relies on the skb_dst() to be present if sip_external_media is set to 1 (which is disabled by default as a module parameter). This effectively disables the sip_external_media toggle for these subsystems without resulting in a crash.

• Обновитесь до 5.15.0-1113.117~20.04.2