May 2022 - Linux-stable-mirror

[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

2 years, 7 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

2 years, 7 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

2 years, 7 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; } }

2 years, 7 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

2 years, 7 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

2 years, 7 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

2 years, 7 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,

2 years, 7 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

2 years, 7 months

2
1
0 0

Re: Patch "um: port_user: Improve error handling when port-helper is not found" has been added to the 5.17-stable tree

by Glenn Washburn

Resending this because stable(a)vger.kernel.org using wrong header field. Apologize for duplicates. On Thu, 19 May 2022 09:52:07 -0400 Sasha Levin <sashal(a)kernel.org> wrote: > This is a note to let you know that I've just added the patch titled > > um: port_user: Improve error handling when port-helper is not found > > to the 5.17-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > um-port_user-improve-error-handling-when-port-helper.patch > and it can be found in the queue-5.17 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. First, I should say that I'm not familiar with the process so I'm likely to be wrong on any number of things. Second I'm the author of this patch and I would like to see this included in the stable trees. However, it appears to me that there is a problem in including just this patch, as it depends on a previous patch which does not appear to be applied[1]. > commit efc324ad7e7e1c92a8862bd71b2f5f8f15513304 > Author: Glenn Washburn <development(a)efficientek.com> > Date: Thu Mar 3 01:53:32 2022 -0600 > > um: port_user: Improve error handling when port-helper is not found > > [ Upstream commit 3cb5a7f167c620a8b0e38b0446df2e024d2243dc ] > > Check if port-helper exists and is executable. If not, write an error > message to the kernel log with information to help the user diagnose the > issue and exit with an error. If UML_PORT_HELPER was not set, write a > message suggesting that the user set it. This makes it easier to understand > why telneting to the UML instance is failing and what can be done to fix it. > > Signed-off-by: Glenn Washburn <development(a)efficientek.com> > Signed-off-by: Richard Weinberger <richard(a)nod.at> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/arch/um/drivers/port_user.c b/arch/um/drivers/port_user.c > index 5b5b64cb1071..133ca7bf2d91 100644 > --- a/arch/um/drivers/port_user.c > +++ b/arch/um/drivers/port_user.c > @@ -5,6 +5,7 @@ > > #include <stdio.h> > #include <stdlib.h> > +#include <string.h> > #include <errno.h> > #include <termios.h> > #include <unistd.h> > @@ -175,6 +176,17 @@ int port_connection(int fd, int *socket, int *pid_out) > if (new < 0) > return -errno; > > + err = os_access(argv[2], X_OK); > + if (err < 0) { > + printk(UM_KERN_ERR "port_connection : error accessing port-helper " > + "executable at %s: %s\n", argv[2], strerror(-err)); > + if (env == NULL) The the afore mentioned patch that this patch depends on "env" is declared and set. Without it, I'd expect this to fail to compile. As such, I may be wrong in that the dependent patch was not already included because I'd expect there to have been a compile test prior to this patch getting to this phase. My suspicion is that the stable trees try to not include new functionality, which the missing patch may have been considered to have done, and thus was not included. If its deemed undesirable to include the missing patch, this "if" block can be removed. Although, I think the missing patch is valuable enough to include. The above goes for all the stable branches that this patch is set to be included in. Glenn [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… > + printk(UM_KERN_ERR "Set UML_PORT_HELPER environment " > + "variable to path to uml-utilities port-helper " > + "binary\n"); > + goto out_close; > + } > + > err = os_pipe(socket, 0, 0); > if (err < 0) > goto out_close;

2 years, 7 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2022