May 2022 - Linux-stable-mirror

by Vic Naluzzi

-- WELCOME TO ILLUMINATI, The Club of the Rich and Famous; is the world oldest and largest fraternity made up of 5 Millions Members.We are one Family under one father who is the Supreme Being. In ILLUMINATI we believe that we were born in paradise and no member should struggle in this world. Hence all our new members are given Money Rewards once they join in order to upgrade their lifestyle.; interested members should contact us via Email: illuminatihome999world(a)gmail.com

3 years, 6 months

1
0
0 0

[PATCH 5.4 0/2] media: vim2m: Fix potential NULL pointer dereference

by Mark-PK Tsai

Backport upstream solution [1][2] to fix below kernel panic: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000208 ... pc : _raw_spin_lock_irqsave+0x50/0x90 lr : v4l2_m2m_cancel_job+0x38/0x1c4 [v4l2_mem2mem] sp : ffffffc012d2bcb0 x29: ffffffc012d2bcb0 x28: ffffff8098d6bb00 x27: 0000000000000000 x26: ffffffc01009b5c8 x25: 00000000000e001f x24: ffffff808ff3eb50 x23: ffffffc01009f5a0 x22: 0000000000000000 x21: ffffff808ffef000 x20: 0000000000000208 x19: 0000000000000000 x18: ffffffc012b51048 x17: ffffffc011e0ef7c x16: 00000000000000c0 x15: ffffffc010fc78f4 x14: ffffffc0119dd790 x13: 0000000000001b26 x12: 0000000053555555 x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000 x8 : 0000000000000208 x7 : 2020202020202020 x6 : ffffffc011e313a6 x5 : 0000000000000000 x4 : 0000000000000008 x3 : 000000000000002e x2 : 0000000000000001 x1 : 0000000000000000 x0 : 0000000000000208 Call trace: _raw_spin_lock_irqsave+0x50/0x90 v4l2_m2m_cancel_job+0x38/0x1c4 [v4l2_mem2mem] v4l2_m2m_ctx_release+0x38/0x60 [v4l2_mem2mem] vim2m_release+0x5c/0xe0 [vim2m] v4l2_release+0x90/0x18c __fput+0xdc/0x2cc ____fput+0x10/0x1c task_work_run+0xc4/0x130 do_notify_resume+0xdc/0x158 work_pending+0x8/0x10 [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Mark-PK Tsai (2): media: vim2m: Register video device after setting up internals media: vim2m: initialize the media device earlier drivers/media/platform/vim2m.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) -- 2.18.0

3 years, 6 months

2
3
0 0

[PATCH 4.14 1/2] tcp: change source port randomizarion at connect() time

by Stefan Ghinea

From: Eric Dumazet <edumazet(a)google.com> commit 190cc82489f46f9d88e73c81a47e14f80a791e1a upstream RFC 6056 (Recommendations for Transport-Protocol Port Randomization) provides good summary of why source selection needs extra care. David Dworken reminded us that linux implements Algorithm 3 as described in RFC 6056 3.3.3 Quoting David : In the context of the web, this creates an interesting info leak where websites can count how many TCP connections a user's computer is establishing over time. For example, this allows a website to count exactly how many subresources a third party website loaded. This also allows: - Distinguishing between different users behind a VPN based on distinct source port ranges. - Tracking users over time across multiple networks. - Covert communication channels between different browsers/browser profiles running on the same computer - Tracking what applications are running on a computer based on the pattern of how fast source ports are getting incremented. Section 3.3.4 describes an enhancement, that reduces attackers ability to use the basic information currently stored into the shared 'u32 hint'. This change also decreases collision rate when multiple applications need to connect() to different destinations. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Reported-by: David Dworken <ddworken(a)google.com> Cc: Willem de Bruijn <willemb(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [SG: Adjusted context] Signed-off-by: Stefan Ghinea <stefan.ghinea(a)windriver.com> --- net/ipv4/inet_hashtables.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c index 1346e45cf8d1..0bc6549c38b1 100644 --- a/net/ipv4/inet_hashtables.c +++ b/net/ipv4/inet_hashtables.c @@ -587,6 +587,17 @@ void inet_unhash(struct sock *sk) } EXPORT_SYMBOL_GPL(inet_unhash); +/* RFC 6056 3.3.4. Algorithm 4: Double-Hash Port Selection Algorithm + * Note that we use 32bit integers (vs RFC 'short integers') + * because 2^16 is not a multiple of num_ephemeral and this + * property might be used by clever attacker. + * RFC claims using TABLE_LENGTH=10 buckets gives an improvement, + * we use 256 instead to really give more isolation and + * privacy, this only consumes 1 KB of kernel memory. + */ +#define INET_TABLE_PERTURB_SHIFT 8 +static u32 table_perturb[1 << INET_TABLE_PERTURB_SHIFT]; + int __inet_hash_connect(struct inet_timewait_death_row *death_row, struct sock *sk, u32 port_offset, int (*check_established)(struct inet_timewait_death_row *, @@ -600,7 +611,7 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row, struct inet_bind_bucket *tb; u32 remaining, offset; int ret, i, low, high; - static u32 hint; + u32 index; if (port) { head = &hinfo->bhash[inet_bhashfn(net, port, @@ -625,7 +636,10 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row, if (likely(remaining > 1)) remaining &= ~1U; - offset = (hint + port_offset) % remaining; + net_get_random_once(table_perturb, sizeof(table_perturb)); + index = hash_32(port_offset, INET_TABLE_PERTURB_SHIFT); + + offset = (READ_ONCE(table_perturb[index]) + port_offset) % remaining; /* In first pass we try ports of @low parity. * inet_csk_get_port() does the opposite choice. */ @@ -678,7 +692,7 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row, return -EADDRNOTAVAIL; ok: - hint += i + 2; + WRITE_ONCE(table_perturb[index], READ_ONCE(table_perturb[index]) + i + 2); /* Head lock still held and bh's disabled */ inet_bind_hash(sk, tb, port); -- 2.36.1

3 years, 6 months

2
2
0 0

[PATCH 5.15] ice: fix crash at allocation failure

by Magnus Karlsson

From: Magnus Karlsson <magnus.karlsson(a)intel.com> Fix a crash in the zero-copy driver that occurs when it fails to allocate buffers from user-space. This crash can easily be triggered by a malicious program that does not provide any buffers in the fill ring for the kernel to use. Note that this bug does not exist in upstream since the batched buffer allocation interface got introduced in 5.16 and replaced this code. Reported-by: Jeff Shaw <jeffrey.b.shaw(a)intel.com> Tested-by: Jeff Shaw <jeffrey.b.shaw(a)intel.com> Signed-off-by: Magnus Karlsson <magnus.karlsson(a)intel.com> --- drivers/net/ethernet/intel/ice/ice_xsk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.c b/drivers/net/ethernet/intel/ice/ice_xsk.c index 2b1873061912..5581747947e5 100644 --- a/drivers/net/ethernet/intel/ice/ice_xsk.c +++ b/drivers/net/ethernet/intel/ice/ice_xsk.c @@ -378,7 +378,7 @@ bool ice_alloc_rx_bufs_zc(struct ice_ring *rx_ring, u16 count) do { *xdp = xsk_buff_alloc(rx_ring->xsk_pool); - if (!xdp) { + if (!*xdp) { ok = false; break; } base-commit: 9f43e3ac7e662f352f829077723fa0b92ccaded1 -- 2.34.1

3 years, 6 months

3
2
0 0

FAILED: patch "[PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID" failed to apply to 5.17-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.17-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 9f46c187e2e680ecd9de7983e4d081c3391acc76 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini <pbonzini(a)redhat.com> Date: Fri, 20 May 2022 13:48:11 -0400 Subject: [PATCH] KVM: x86/mmu: fix NULL pointer dereference on guest INVPCID With shadow paging enabled, the INVPCID instruction results in a call to kvm_mmu_invpcid_gva. If INVPCID is executed with CR0.PG=0, the invlpg callback is not set and the result is a NULL pointer dereference. Fix it trivially by checking for mmu->invlpg before every call. There are other possibilities: - check for CR0.PG, because KVM (like all Intel processors after P5) flushes guest TLB on CR0.PG changes so that INVPCID/INVLPG are a nop with paging disabled - check for EFER.LMA, because KVM syncs and flushes when switching MMU contexts outside of 64-bit mode All of these are tricky, go for the simple solution. This is CVE-2022-1789. Reported-by: Yongkang Jia <kangel(a)zju.edu.cn> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 56ebc4fb7f91..45e1573f8f1d 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -5470,14 +5470,16 @@ void kvm_mmu_invpcid_gva(struct kvm_vcpu *vcpu, gva_t gva, unsigned long pcid) uint i; if (pcid == kvm_get_active_pcid(vcpu)) { - mmu->invlpg(vcpu, gva, mmu->root.hpa); + if (mmu->invlpg) + mmu->invlpg(vcpu, gva, mmu->root.hpa); tlb_flush = true; } for (i = 0; i < KVM_MMU_NUM_PREV_ROOTS; i++) { if (VALID_PAGE(mmu->prev_roots[i].hpa) && pcid == kvm_get_pcid(vcpu, mmu->prev_roots[i].pgd)) { - mmu->invlpg(vcpu, gva, mmu->prev_roots[i].hpa); + if (mmu->invlpg) + mmu->invlpg(vcpu, gva, mmu->prev_roots[i].hpa); tlb_flush = true; } }

3 years, 6 months

3
6
0 0

[PATCH 5.10] KVM: x86: Properly handle APF vs disabled LAPIC situation

by Guoqing Jiang

From: Vitaly Kuznetsov <vkuznets(a)redhat.com> Backport of commit 2f15d027c05fac406decdb5eceb9ec0902b68f53 upstream. Async PF 'page ready' event may happen when LAPIC is (temporary) disabled. In particular, Sebastien reports that when Linux kernel is directly booted by Cloud Hypervisor, LAPIC is 'software disabled' when APF mechanism is initialized. On initialization KVM tries to inject 'wakeup all' event and puts the corresponding token to the slot. It is, however, failing to inject an interrupt (kvm_apic_set_irq() -> __apic_accept_irq() -> !apic_enabled()) so the guest never gets notified and the whole APF mechanism gets stuck. The same issue is likely to happen if the guest temporary disables LAPIC and a previously unavailable page becomes available. Do two things to resolve the issue: - Avoid dequeuing 'page ready' events from APF queue when LAPIC is disabled. - Trigger an attempt to deliver pending 'page ready' events when LAPIC becomes enabled (SPIV or MSR_IA32_APICBASE). Reported-by: Sebastien Boeuf <sebastien.boeuf(a)intel.com> Signed-off-by: Vitaly Kuznetsov <vkuznets(a)redhat.com> Message-Id: <20210422092948.568327-1-vkuznets(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> [Guoqing: backport to 5.10-stable ] Signed-off-by: Guoqing Jiang <guoqing.jiang(a)linux.dev> --- Hi, We encountered below task hang issue with 5.10.113 stable kernel. [ 246.845061] INFO: task rpmbuild:2303 blocked for more than 122 seconds. [ 246.846269] Not tainted 5.10.113-1.1.se2-default #1 [ 246.847103] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.848248] task:rpmbuild state:D stack: 0 pid: 2303 ppid: 2302 flags:0x00000000 [ 246.848252] Call Trace: [ 246.848266] __schedule+0x3f6/0x7c0 [ 246.848289] ? __handle_mm_fault+0x3dd/0x6d0 [ 246.848291] schedule+0x46/0xb0 [ 246.848295] kvm_async_pf_task_wait_schedule+0x4b/0x90 [ 246.848297] ? handle_mm_fault+0xbc/0x280 [ 246.848300] __kvm_handle_async_pf+0x4f/0xb0 [ 246.848303] exc_page_fault+0x204/0x540 [ 246.848305] ? asm_exc_page_fault+0x8/0x30 [ 246.848307] asm_exc_page_fault+0x1e/0x30 [ 246.848310] RIP: 0033:0x7f122fbdfc90 And after investigating, this patch resolve the issue. 5.12 stable kernel has already merged it by commit 36825931c607. Thanks, Guoqing arch/x86/kvm/lapic.c | 6 ++++++ arch/x86/kvm/x86.c | 2 +- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c index a3ef793fce5f..6ed6b090be94 100644 --- a/arch/x86/kvm/lapic.c +++ b/arch/x86/kvm/lapic.c @@ -297,6 +297,10 @@ static inline void apic_set_spiv(struct kvm_lapic *apic, u32 val) atomic_set_release(&apic->vcpu->kvm->arch.apic_map_dirty, DIRTY); } + + /* Check if there are APF page ready requests pending */ + if (enabled) + kvm_make_request(KVM_REQ_APF_READY, apic->vcpu); } static inline void kvm_apic_set_xapic_id(struct kvm_lapic *apic, u8 id) @@ -2260,6 +2264,8 @@ void kvm_lapic_set_base(struct kvm_vcpu *vcpu, u64 value) if (value & MSR_IA32_APICBASE_ENABLE) { kvm_apic_set_xapic_id(apic, vcpu->vcpu_id); static_key_slow_dec_deferred(&apic_hw_disabled); + /* Check if there are APF page ready requests pending */ + kvm_make_request(KVM_REQ_APF_READY, vcpu); } else { static_key_slow_inc(&apic_hw_disabled.key); atomic_set_release(&apic->vcpu->kvm->arch.apic_map_dirty, DIRTY); diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 4588f73bf59a..ae18062c26a6 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11146,7 +11146,7 @@ bool kvm_arch_can_dequeue_async_page_present(struct kvm_vcpu *vcpu) if (!kvm_pv_async_pf_enabled(vcpu)) return true; else - return apf_pageready_slot_free(vcpu); + return kvm_lapic_enabled(vcpu) && apf_pageready_slot_free(vcpu); } void kvm_arch_start_assignment(struct kvm *kvm) -- 2.34.1

3 years, 6 months

2
1
0 0

goodix: Commit for 5.4 stable inclusion

by Fabio Estevam

Hi, I would like to kindly request the inclusion of commit 24ef83f6e31d ("Input: goodix - fix spurious key release events") to the 5.4 stable tree. It fixes the spurious touches reported on an imx6dl board with Goodix GT911 running kernel 5.4. Thanks, Fabio Estevam

3 years, 6 months

2
1
0 0

[PATCH] staging: r8188eu: prevent ->Ssid overflow in rtw_wx_set_scan()

by Denis Efremov

This code has a check to prevent read overflow but it needs another check to prevent writing beyond the end of the ->Ssid[] array. Fixes: 2b42bd58b321 ("staging: r8188eu: introduce new os_dep dir for RTL8188eu driver") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Denis Efremov <denis.e.efremov(a)oracle.com> --- This patch is a copy of Dan's 74b6b20df8cf (CVE-2021-28660). Drivers r8188eu and rtl8188eu share the same code. drivers/staging/r8188eu/os_dep/ioctl_linux.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/r8188eu/os_dep/ioctl_linux.c b/drivers/staging/r8188eu/os_dep/ioctl_linux.c index eb9375b0c660..a2692ce02bc2 100644 --- a/drivers/staging/r8188eu/os_dep/ioctl_linux.c +++ b/drivers/staging/r8188eu/os_dep/ioctl_linux.c @@ -1131,9 +1131,11 @@ static int rtw_wx_set_scan(struct net_device *dev, struct iw_request_info *a, break; } sec_len = *(pos++); len -= 1; - if (sec_len > 0 && sec_len <= len) { + if (sec_len > 0 && + sec_len <= len && + sec_len <= 32) { ssid[ssid_index].SsidLength = sec_len; - memcpy(ssid[ssid_index].Ssid, pos, ssid[ssid_index].SsidLength); + memcpy(ssid[ssid_index].Ssid, pos, sec_len); ssid_index++; } pos += sec_len; -- 2.35.3

3 years, 6 months

5
10
0 0

AMD SFH sensor discovery

by Limonciello, Mario

[Public] Hi, The firmware on some OEM laptops with AMD SOCs advertise that they have sensors connected to AMD SFH but they really don't physically have them. In 5.19 a commit has gone in that discovers this case and prevents the driver from advertising this sensor to userspace. This might not seem like a big deal to have sensors advertised that aren't really there, but AMD has observed that specifically on orientation sensors the random garbage data associated can cause userspace to interpret a screen rotation during resume from suspend. As GNOME has a daemon running that interprets these events I've seen first hand that it can cause the display go upside down without a lot of recourse other than command line tools or rebooting. Can you please backport this commit to 5.15.y+ and later to fix this: commit b5d7f43e97dabfa04a4be5ff027ce7da119332be ("HID: amd_sfh: Add support for sensor discovery") Thanks,

3 years, 6 months

2
1
0 0

[PATCH] hugetlb: fix huge_pmd_unshare address update

by Mike Kravetz

The routine huge_pmd_unshare is passed a pointer to an address associated with an area which may be unshared. If unshare is successful this address is updated to 'optimize' callers iterating over huge page addresses. For the optimization to work correctly, address should be updated to the last huge page in the unmapped/unshared area. However, in the common case where the passed address is PUD_SIZE aligned, the address is incorrectly updated to the address of the preceding huge page. That wastes CPU cycles as the unmapped/unshared range is scanned twice. Cc: <stable(a)vger.kernel.org> Fixes: 39dde65c9940 ("shared page table for hugetlb page") Signed-off-by: Mike Kravetz <mike.kravetz(a)oracle.com> --- mm/hugetlb.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 01f0e2e5ab48..7c468ac1d069 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -6755,7 +6755,14 @@ int huge_pmd_unshare(struct mm_struct *mm, struct vm_area_struct *vma, pud_clear(pud); put_page(virt_to_page(ptep)); mm_dec_nr_pmds(mm); - *addr = ALIGN(*addr, HPAGE_SIZE * PTRS_PER_PTE) - HPAGE_SIZE; + /* + * This update of passed address optimizes loops sequentially + * processing addresses in increments of huge page size (PMD_SIZE + * in this case). By clearing the pud, a PUD_SIZE area is unmapped. + * Update address to the 'last page' in the cleared area so that + * calling loop can move to first page past this area. + */ + *addr |= PUD_SIZE - PMD_SIZE; return 1; } -- 2.35.3

3 years, 6 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2022