May 2021 - Linux-stable-mirror

[PATCH 1/2] KVM: SVM: avoid infinite loop on NPF from bad address

by Paolo Bonzini

When a nested page fault is taken from an address that does not have a memslot associated to it, kvm_mmu_do_page_fault returns RET_PF_EMULATE (via mmu_set_spte) and kvm_mmu_page_fault then invokes svm_need_emulation_on_page_fault. The default answer there is to return false, but in this case this just causes the page fault to be retried ad libitum. Since this is not a fast path, and the only other case where it is taken is an erratum, just stick a kvm_vcpu_gfn_to_memslot check in there to detect the common case where the erratum is not happening. This fixes an infinite loop in the new set_memory_region_test. Fixes: 05d5a4863525 ("KVM: SVM: Workaround errata#1096 (insn_len maybe zero on SMAP violation)") Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/kvm/svm/svm.c | 7 +++++++ virt/kvm/kvm_main.c | 1 + 2 files changed, 8 insertions(+) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index a91e397d6750..c86f7278509b 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -3837,6 +3837,13 @@ static bool svm_need_emulation_on_page_fault(struct kvm_vcpu *vcpu) bool smap = cr4 & X86_CR4_SMAP; bool is_user = svm_get_cpl(vcpu) == 3; + /* + * If RIP is invalid, go ahead with emulation which will cause an + * internal error exit. + */ + if (!kvm_vcpu_gfn_to_memslot(vcpu, kvm_rip_read(vcpu) >> PAGE_SHIFT)) + return true; + /* * Detect and workaround Errata 1096 Fam_17h_00_0Fh. * diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index e2f60e313c87..e7436d054305 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -1602,6 +1602,7 @@ struct kvm_memory_slot *kvm_vcpu_gfn_to_memslot(struct kvm_vcpu *vcpu, gfn_t gfn { return __gfn_to_memslot(kvm_vcpu_memslots(vcpu), gfn); } +EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_memslot); bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn) { -- 2.18.2

3 years, 6 months

4
7
0 0

FAILED: patch "[PATCH] KVM: SVM: Truncate GPR value for DR and CR accesses in" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-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 0884335a2e653b8a045083aa1d57ce74269ac81d Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Wed, 21 Apr 2021 19:21:22 -0700 Subject: [PATCH] KVM: SVM: Truncate GPR value for DR and CR accesses in !64-bit mode Drop bits 63:32 on loads/stores to/from DRs and CRs when the vCPU is not in 64-bit mode. The APM states bits 63:32 are dropped for both DRs and CRs: In 64-bit mode, the operand size is fixed at 64 bits without the need for a REX prefix. In non-64-bit mode, the operand size is fixed at 32 bits and the upper 32 bits of the destination are forced to 0. Fixes: 7ff76d58a9dc ("KVM: SVM: enhance MOV CR intercept handler") Fixes: cae3797a4639 ("KVM: SVM: enhance mov DR intercept handler") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20210422022128.3464144-4-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 301792542937..857bcf3a4cda 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2451,7 +2451,7 @@ static int cr_interception(struct kvm_vcpu *vcpu) err = 0; if (cr >= 16) { /* mov to cr */ cr -= 16; - val = kvm_register_read(vcpu, reg); + val = kvm_register_readl(vcpu, reg); trace_kvm_cr_write(cr, val); switch (cr) { case 0: @@ -2497,7 +2497,7 @@ static int cr_interception(struct kvm_vcpu *vcpu) kvm_queue_exception(vcpu, UD_VECTOR); return 1; } - kvm_register_write(vcpu, reg, val); + kvm_register_writel(vcpu, reg, val); trace_kvm_cr_read(cr, val); } return kvm_complete_insn_gp(vcpu, err); @@ -2563,11 +2563,11 @@ static int dr_interception(struct kvm_vcpu *vcpu) dr = svm->vmcb->control.exit_code - SVM_EXIT_READ_DR0; if (dr >= 16) { /* mov to DRn */ dr -= 16; - val = kvm_register_read(vcpu, reg); + val = kvm_register_readl(vcpu, reg); err = kvm_set_dr(vcpu, dr, val); } else { kvm_get_dr(vcpu, dr, &val); - kvm_register_write(vcpu, reg, val); + kvm_register_writel(vcpu, reg, val); } return kvm_complete_insn_gp(vcpu, err);

3 years, 6 months

2
1
0 0

FAILED: patch "[PATCH] KVM: SVM: Truncate GPR value for DR and CR accesses in" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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 0884335a2e653b8a045083aa1d57ce74269ac81d Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Wed, 21 Apr 2021 19:21:22 -0700 Subject: [PATCH] KVM: SVM: Truncate GPR value for DR and CR accesses in !64-bit mode Drop bits 63:32 on loads/stores to/from DRs and CRs when the vCPU is not in 64-bit mode. The APM states bits 63:32 are dropped for both DRs and CRs: In 64-bit mode, the operand size is fixed at 64 bits without the need for a REX prefix. In non-64-bit mode, the operand size is fixed at 32 bits and the upper 32 bits of the destination are forced to 0. Fixes: 7ff76d58a9dc ("KVM: SVM: enhance MOV CR intercept handler") Fixes: cae3797a4639 ("KVM: SVM: enhance mov DR intercept handler") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20210422022128.3464144-4-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 301792542937..857bcf3a4cda 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2451,7 +2451,7 @@ static int cr_interception(struct kvm_vcpu *vcpu) err = 0; if (cr >= 16) { /* mov to cr */ cr -= 16; - val = kvm_register_read(vcpu, reg); + val = kvm_register_readl(vcpu, reg); trace_kvm_cr_write(cr, val); switch (cr) { case 0: @@ -2497,7 +2497,7 @@ static int cr_interception(struct kvm_vcpu *vcpu) kvm_queue_exception(vcpu, UD_VECTOR); return 1; } - kvm_register_write(vcpu, reg, val); + kvm_register_writel(vcpu, reg, val); trace_kvm_cr_read(cr, val); } return kvm_complete_insn_gp(vcpu, err); @@ -2563,11 +2563,11 @@ static int dr_interception(struct kvm_vcpu *vcpu) dr = svm->vmcb->control.exit_code - SVM_EXIT_READ_DR0; if (dr >= 16) { /* mov to DRn */ dr -= 16; - val = kvm_register_read(vcpu, reg); + val = kvm_register_readl(vcpu, reg); err = kvm_set_dr(vcpu, dr, val); } else { kvm_get_dr(vcpu, dr, &val); - kvm_register_write(vcpu, reg, val); + kvm_register_writel(vcpu, reg, val); } return kvm_complete_insn_gp(vcpu, err);

3 years, 6 months

2
1
0 0

FAILED: patch "[PATCH] KVM: SVM: Truncate GPR value for DR and CR accesses in" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-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 0884335a2e653b8a045083aa1d57ce74269ac81d Mon Sep 17 00:00:00 2001 From: Sean Christopherson <seanjc(a)google.com> Date: Wed, 21 Apr 2021 19:21:22 -0700 Subject: [PATCH] KVM: SVM: Truncate GPR value for DR and CR accesses in !64-bit mode Drop bits 63:32 on loads/stores to/from DRs and CRs when the vCPU is not in 64-bit mode. The APM states bits 63:32 are dropped for both DRs and CRs: In 64-bit mode, the operand size is fixed at 64 bits without the need for a REX prefix. In non-64-bit mode, the operand size is fixed at 32 bits and the upper 32 bits of the destination are forced to 0. Fixes: 7ff76d58a9dc ("KVM: SVM: enhance MOV CR intercept handler") Fixes: cae3797a4639 ("KVM: SVM: enhance mov DR intercept handler") Cc: stable(a)vger.kernel.org Signed-off-by: Sean Christopherson <seanjc(a)google.com> Message-Id: <20210422022128.3464144-4-seanjc(a)google.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index 301792542937..857bcf3a4cda 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -2451,7 +2451,7 @@ static int cr_interception(struct kvm_vcpu *vcpu) err = 0; if (cr >= 16) { /* mov to cr */ cr -= 16; - val = kvm_register_read(vcpu, reg); + val = kvm_register_readl(vcpu, reg); trace_kvm_cr_write(cr, val); switch (cr) { case 0: @@ -2497,7 +2497,7 @@ static int cr_interception(struct kvm_vcpu *vcpu) kvm_queue_exception(vcpu, UD_VECTOR); return 1; } - kvm_register_write(vcpu, reg, val); + kvm_register_writel(vcpu, reg, val); trace_kvm_cr_read(cr, val); } return kvm_complete_insn_gp(vcpu, err); @@ -2563,11 +2563,11 @@ static int dr_interception(struct kvm_vcpu *vcpu) dr = svm->vmcb->control.exit_code - SVM_EXIT_READ_DR0; if (dr >= 16) { /* mov to DRn */ dr -= 16; - val = kvm_register_read(vcpu, reg); + val = kvm_register_readl(vcpu, reg); err = kvm_set_dr(vcpu, dr, val); } else { kvm_get_dr(vcpu, dr, &val); - kvm_register_write(vcpu, reg, val); + kvm_register_writel(vcpu, reg, val); } return kvm_complete_insn_gp(vcpu, err);

3 years, 6 months

2
1
0 0

[PATCH 3/3] media: rtl28xxu: fix zero-length control request

by Johan Hovold

The direction of the pipe argument must match the request-type direction bit or control requests may fail depending on the host-controller-driver implementation. Control transfers without a data stage are treated as OUT requests by the USB stack and should be using usb_sndctrlpipe(). Failing to do so will now trigger a warning. Fix the zero-length i2c-read request used for type detection by attempting to read a single byte instead. Reported-by: syzbot+faf11bbadc5a372564da(a)syzkaller.appspotmail.com Fixes: d0f232e823af ("[media] rtl28xxu: add heuristic to detect chip type") Cc: stable(a)vger.kernel.org # 4.0 Cc: Antti Palosaari <crope(a)iki.fi> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 97ed17a141bb..2c04ed8af0e4 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -612,8 +612,9 @@ static int rtl28xxu_read_config(struct dvb_usb_device *d) static int rtl28xxu_identify_state(struct dvb_usb_device *d, const char **name) { struct rtl28xxu_dev *dev = d_to_priv(d); + u8 buf[1]; int ret; - struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 0, NULL}; + struct rtl28xxu_req req_demod_i2c = {0x0020, CMD_I2C_DA_RD, 1, buf}; dev_dbg(&d->intf->dev, "\n"); -- 2.26.3

3 years, 6 months

1
2
0 0

[PATCH v2] media: videobuf2: Fix integer overrun in vb2_mmap

by Ricardo Ribalda

The plane_length is an unsigned integer. So, if we have a size of 0xffffffff bytes we incorrectly allocate 0 bytes instead of 1 << 32. Suggested-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Cc: stable(a)vger.kernel.org Fixes: 7f8414594e47 ("[media] media: videobuf2: fix the length check for mmap") Reviewed-by: Sergey Senozhatsky <senozhatsky(a)chromium.org> Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- drivers/media/common/videobuf2/videobuf2-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/common/videobuf2/videobuf2-core.c b/drivers/media/common/videobuf2/videobuf2-core.c index 543da515c761..89c8bacb94a7 100644 --- a/drivers/media/common/videobuf2/videobuf2-core.c +++ b/drivers/media/common/videobuf2/videobuf2-core.c @@ -2256,7 +2256,7 @@ int vb2_mmap(struct vb2_queue *q, struct vm_area_struct *vma) * The buffer length was page_aligned at __vb2_buf_mem_alloc(), * so, we need to do the same here. */ - length = PAGE_ALIGN(vb->planes[plane].length); + length = PAGE_ALIGN((unsigned long)vb->planes[plane].length); if (length < (vma->vm_end - vma->vm_start)) { dprintk(q, 1, "MMAP invalid, as it would overflow buffer length\n"); -- 2.30.1.766.gb4fecdf3b7-goog

3 years, 6 months

3
2
0 0

[PATCH] fscrypt: fix derivation of SipHash keys on big endian CPUs

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> Typically, the cryptographic APIs that fscrypt uses take keys as byte arrays, which avoids endianness issues. However, siphash_key_t is an exception. It is defined as 'u64 key[2];', i.e. the 128-bit key is expected to be given directly as two 64-bit words in CPU endianness. fscrypt_derive_dirhash_key() forgot to take this into account. Therefore, the SipHash keys used to index encrypted+casefolded directories differ on big endian vs. little endian platforms. This makes such directories non-portable between these platforms. Fix this by always using the little endian order. This is a breaking change for big endian platforms, but this should be fine in practice since the encrypt+casefold support isn't known to actually be used on any big endian platforms yet. Fixes: aa408f835d02 ("fscrypt: derive dirhash key for casefolded directories") Cc: <stable(a)vger.kernel.org> # v5.6+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/crypto/keysetup.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/crypto/keysetup.c b/fs/crypto/keysetup.c index 261293fb7097..4d98377c07a7 100644 --- a/fs/crypto/keysetup.c +++ b/fs/crypto/keysetup.c @@ -221,6 +221,16 @@ int fscrypt_derive_dirhash_key(struct fscrypt_info *ci, sizeof(ci->ci_dirhash_key)); if (err) return err; + + /* + * The SipHash APIs expect the key as a pair of 64-bit words, not as a + * byte array. Make sure to use a consistent endianness. + */ + BUILD_BUG_ON(sizeof(ci->ci_dirhash_key) != 16); + BUILD_BUG_ON(ARRAY_SIZE(ci->ci_dirhash_key.key) != 2); + le64_to_cpus(&ci->ci_dirhash_key.key[0]); + le64_to_cpus(&ci->ci_dirhash_key.key[1]); + ci->ci_dirhash_key_initialized = true; return 0; } -- 2.32.0.rc0.204.g9fa02ecfa5-goog

3 years, 6 months

1
1
0 0

[PATCH] fscrypt: don't ignore minor_hash when hash is 0

by Eric Biggers

From: Eric Biggers <ebiggers(a)google.com> When initializing a no-key name, fscrypt_fname_disk_to_usr() sets the minor_hash to 0 if the (major) hash is 0. This doesn't make sense because 0 is a valid hash code, so we shouldn't ignore the filesystem-provided minor_hash in that case. Fix this by removing the special case for 'hash == 0'. This is an old bug that appears to have originated when the encryption code in ext4 and f2fs was moved into fs/crypto/. The original ext4 and f2fs code passed the hash by pointer instead of by value. So 'if (hash)' actually made sense then, as it was checking whether a pointer was NULL. But now the hashes are passed by value, and filesystems just pass 0 for any hashes they don't have. There is no need to handle this any differently from the hashes actually being 0. It is difficult to reproduce this bug, as it only made a difference in the case where a filename's 32-bit major hash happened to be 0. However, it probably had the largest chance of causing problems on ubifs, since ubifs uses minor_hash to do lookups of no-key names, in addition to using it as a readdir cookie. ext4 only uses minor_hash as a readdir cookie, and f2fs doesn't use minor_hash at all. Fixes: 0b81d0779072 ("fs crypto: move per-file encryption from f2fs tree to fs/crypto") Cc: <stable(a)vger.kernel.org> # v4.6+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> --- fs/crypto/fname.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/fs/crypto/fname.c b/fs/crypto/fname.c index 6ca7d16593ff..d00455440d08 100644 --- a/fs/crypto/fname.c +++ b/fs/crypto/fname.c @@ -344,13 +344,9 @@ int fscrypt_fname_disk_to_usr(const struct inode *inode, offsetof(struct fscrypt_nokey_name, sha256)); BUILD_BUG_ON(BASE64_CHARS(FSCRYPT_NOKEY_NAME_MAX) > NAME_MAX); - if (hash) { - nokey_name.dirhash[0] = hash; - nokey_name.dirhash[1] = minor_hash; - } else { - nokey_name.dirhash[0] = 0; - nokey_name.dirhash[1] = 0; - } + nokey_name.dirhash[0] = hash; + nokey_name.dirhash[1] = minor_hash; + if (iname->len <= sizeof(nokey_name.bytes)) { memcpy(nokey_name.bytes, iname->name, iname->len); size = offsetof(struct fscrypt_nokey_name, bytes[iname->len]); base-commit: c4681547bcce777daf576925a966ffa824edd09d -- 2.32.0.rc0.204.g9fa02ecfa5-goog

3 years, 6 months

1
1
0 0

[PATCH v2 1/5] arm64: kexec_file: Forbid non-crash kernels

by Marc Zyngier

It has been reported that kexec_file doesn't really work on arm64. It completely ignores any of the existing reservations, which results in the secondary kernel being loaded where the GICv3 LPI tables live, or even corrupting the ACPI tables. Since only crash kernels are imune to this as they use a reserved memory region, disable the non-crash kernel use case. Further patches will try and restore the functionality. Reported-by: Moritz Fischer <mdf(a)kernel.org> Signed-off-by: Marc Zyngier <maz(a)kernel.org> Cc: stable(a)vger.kernel.org # 5.10 --- arch/arm64/kernel/kexec_image.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c index 9ec34690e255..acf9cd251307 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -145,3 +145,23 @@ const struct kexec_file_ops kexec_image_ops = { .verify_sig = image_verify_sig, #endif }; + +/** + * arch_kexec_locate_mem_hole - Find free memory to place the segments. + * @kbuf: Parameters for the memory search. + * + * On success, kbuf->mem will have the start address of the memory region found. + * + * Return: 0 on success, negative errno on error. + */ +int arch_kexec_locate_mem_hole(struct kexec_buf *kbuf) +{ + /* + * For the time being, kexec_file_load isn't reliable except + * for crash kernel. Say sorry to the user. + */ + if (kbuf->image->type != KEXEC_TYPE_CRASH) + return -EADDRNOTAVAIL; + + return kexec_locate_mem_hole(kbuf); +} -- 2.30.2

3 years, 6 months

3
3
0 0

[PATCH] xfrm: policy: Read seqcount outside of rcu-read side in xfrm_policy_lookup_bytype

by Varad Gautam

xfrm_policy_lookup_bytype loops on seqcount mutex xfrm_policy_hash_generation within an RCU read side critical section. Although ill advised, this is fine if the loop is bounded. xfrm_policy_hash_generation wraps mutex hash_resize_mutex, which is used to serialize writers (xfrm_hash_resize, xfrm_hash_rebuild). This is fine too. On PREEMPT_RT=y, the read_seqcount_begin call within xfrm_policy_lookup_bytype emits a mutex lock/unlock for hash_resize_mutex. Mutex locking is fine, since RCU read side critical sections are allowed to sleep with PREEMPT_RT. xfrm_hash_resize can, however, block on synchronize_rcu while holding hash_resize_mutex. This leads to the following situation on PREEMPT_RT, where the writer is blocked on RCU grace period expiry, while the reader is blocked on a lock held by the writer: Thead 1 (xfrm_hash_resize) Thread 2 (xfrm_policy_lookup_bytype) rcu_read_lock(); mutex_lock(&hash_resize_mutex); read_seqcount_begin(&xfrm_policy_hash_generation); mutex_lock(&hash_resize_mutex); // block xfrm_bydst_resize(); synchronize_rcu(); // block <RCU stalls in xfrm_policy_lookup_bytype> Move the read_seqcount_begin call outside of the RCU read side critical section, and do an rcu_read_unlock/retry if we got stale data within the critical section. On non-PREEMPT_RT, this shortens the time spent within RCU read side critical section in case the seqcount needs a retry, and avoids unbounded looping. Fixes: a7c44247f70 ("xfrm: policy: make xfrm_policy_lookup_bytype lockless") Signed-off-by: Varad Gautam <varad.gautam(a)suse.com> Cc: linux-rt-users <linux-rt-users(a)vger.kernel.org> Cc: netdev(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v4.9 Cc: Steffen Klassert <steffen.klassert(a)secunet.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: Jakub Kicinski <kuba(a)kernel.org> Cc: Florian Westphal <fw(a)strlen.de> --- net/xfrm/xfrm_policy.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index ce500f847b99..e9d0df2a2ab1 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -2092,12 +2092,15 @@ static struct xfrm_policy *xfrm_policy_lookup_bytype(struct net *net, u8 type, if (unlikely(!daddr || !saddr)) return NULL; - rcu_read_lock(); retry: - do { - sequence = read_seqcount_begin(&xfrm_policy_hash_generation); - chain = policy_hash_direct(net, daddr, saddr, family, dir); - } while (read_seqcount_retry(&xfrm_policy_hash_generation, sequence)); + sequence = read_seqcount_begin(&xfrm_policy_hash_generation); + rcu_read_lock(); + + chain = policy_hash_direct(net, daddr, saddr, family, dir); + if (read_seqcount_retry(&xfrm_policy_hash_generation, sequence)) { + rcu_read_unlock(); + goto retry; + } ret = NULL; hlist_for_each_entry_rcu(pol, chain, bydst) { @@ -2128,11 +2131,15 @@ static struct xfrm_policy *xfrm_policy_lookup_bytype(struct net *net, u8 type, } skip_inexact: - if (read_seqcount_retry(&xfrm_policy_hash_generation, sequence)) + if (read_seqcount_retry(&xfrm_policy_hash_generation, sequence)) { + rcu_read_unlock(); goto retry; + } - if (ret && !xfrm_pol_hold_rcu(ret)) + if (ret && !xfrm_pol_hold_rcu(ret)) { + rcu_read_unlock(); goto retry; + } fail: rcu_read_unlock(); -- 2.26.2

3 years, 6 months

3
5
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2021