This is the start of the stable review cycle for the 5.15.160 release.
There are 23 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 25 May 2024 13:03:15 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.15.160-r…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.15.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 5.15.160-rc1
Akira Yokosawa <akiyks(a)gmail.com>
docs: kernel_include.py: Cope with docutils 0.21
Thomas Weißschuh <linux(a)weissschuh.net>
admin-guide/hw-vuln/core-scheduling: fix return type of PR_SCHED_CORE_GET
Jarkko Sakkinen <jarkko(a)kernel.org>
KEYS: trusted: Do not use WARN when encode fails
AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com>
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
Daniel Thompson <daniel.thompson(a)linaro.org>
serial: kgdboc: Fix NMI-safety problems from keyboard reset code
Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
usb: typec: ucsi: displayport: Fix potential deadlock
Carlos Llamas <cmllamas(a)google.com>
binder: fix max_thread type inconsistency
Srinivasan Shanmugam <srinivasan.shanmugam(a)amd.com>
drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper()
Sean Christopherson <seanjc(a)google.com>
KVM: x86: Clear "has_error_code", not "error_code", for RM exception injection
Eric Dumazet <edumazet(a)google.com>
netlink: annotate data-races around sk->sk_err
Eric Dumazet <edumazet(a)google.com>
netlink: annotate lockless accesses to nlk->max_recvmsg_len
Jakub Kicinski <kuba(a)kernel.org>
net: tls: handle backlogging of crypto requests
Jakub Kicinski <kuba(a)kernel.org>
tls: fix race between async notify and socket close
Jakub Kicinski <kuba(a)kernel.org>
net: tls: factor out tls_*crypt_async_wait()
Sabrina Dubroca <sd(a)queasysnail.net>
tls: extract context alloc/initialization out of tls_set_sw_offload
Jakub Kicinski <kuba(a)kernel.org>
tls: rx: simplify async wait
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: synchronize UMAC_CMD access
Doug Berger <opendmb(a)gmail.com>
net: bcmgenet: synchronize EXT_RGMII_OOB_CTRL access
Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com>
Revert "selftests: mm: fix map_hugetlb failure on 64K page size systems"
Jarkko Sakkinen <jarkko(a)kernel.org>
KEYS: trusted: Fix memory leak in tpm2_key_encode()
NeilBrown <neilb(a)suse.de>
nfsd: don't allow nfsd threads to be signalled.
Sergey Shtylyov <s.shtylyov(a)omp.ru>
pinctrl: core: handle radix_tree_insert() errors in pinctrl_register_one_pin()
Jose Fernandez <josef(a)netflix.com>
drm/amd/display: Fix division by zero in setup_dsc_config
-------------
Diffstat:
.../admin-guide/hw-vuln/core-scheduling.rst | 4 +-
Documentation/sphinx/kernel_include.py | 1 -
Makefile | 4 +-
arch/x86/kvm/x86.c | 11 +-
drivers/android/binder.c | 2 +-
drivers/android/binder_internal.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c | 3 +
drivers/gpu/drm/amd/display/dc/dsc/dc_dsc.c | 7 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 12 +-
drivers/net/ethernet/broadcom/genet/bcmgenet.h | 2 +
drivers/net/ethernet/broadcom/genet/bcmgenet_wol.c | 6 +
drivers/net/ethernet/broadcom/genet/bcmmii.c | 4 +
drivers/pinctrl/core.c | 14 +-
drivers/remoteproc/mtk_scp.c | 10 +-
drivers/tty/serial/kgdboc.c | 30 +++-
drivers/usb/typec/ucsi/displayport.c | 4 -
fs/nfs/callback.c | 9 +-
fs/nfsd/nfs4proc.c | 5 +-
fs/nfsd/nfssvc.c | 12 --
include/net/tls.h | 6 -
net/netlink/af_netlink.c | 23 +--
net/sunrpc/svc_xprt.c | 16 +-
net/tls/tls_sw.c | 199 +++++++++++----------
security/keys/trusted-keys/trusted_tpm2.c | 25 ++-
tools/testing/selftests/vm/map_hugetlb.c | 7 -
25 files changed, 243 insertions(+), 175 deletions(-)
On Thu, 6 Jun 2024 at 01:11, Sasha Levin <sashal(a)kernel.org> wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> arm64: fpsimd: Bring cond_yield asm macro in line with new rules
>
> to the 6.6-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:
> arm64-fpsimd-bring-cond_yield-asm-macro-in-line-with.patch
> and it can be found in the queue-6.6 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.
>
NAK
None of these changes belong in v6.6 - please drop all of them.
From: Kan Liang <kan.liang(a)linux.intel.com>
The hard-coded metrics is wrongly calculated on the hybrid machine.
$ perf stat -e cycles,instructions -a sleep 1
Performance counter stats for 'system wide':
18,205,487 cpu_atom/cycles/
9,733,603 cpu_core/cycles/
9,423,111 cpu_atom/instructions/ # 0.52 insn per cycle
4,268,965 cpu_core/instructions/ # 0.23 insn per cycle
The insn per cycle for cpu_core should be 4,268,965 / 9,733,603 = 0.44.
When finding the metric events, the find_stat() doesn't take the PMU
type into account. The cpu_atom/cycles/ is wrongly used to calculate
the IPC of the cpu_core.
Fixes: 0a57b910807a ("perf stat: Use counts rather than saved_value")
Reported-by: "Khalil, Amiri" <amiri.khalil(a)intel.com>
Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
---
tools/perf/util/stat-shadow.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/perf/util/stat-shadow.c b/tools/perf/util/stat-shadow.c
index 3466aa952442..4d0edc061f1a 100644
--- a/tools/perf/util/stat-shadow.c
+++ b/tools/perf/util/stat-shadow.c
@@ -176,6 +176,10 @@ static double find_stat(const struct evsel *evsel, int aggr_idx, enum stat_type
if (type != evsel__stat_type(cur))
continue;
+ /* Ignore if not the PMU we're looking for. */
+ if (evsel->pmu != cur->pmu)
+ continue;
+
aggr = &cur->stats->aggr[aggr_idx];
if (type == STAT_NSECS)
return aggr->counts.val;
--
2.35.1
On Thu, 30 May 2024 at 21:11, Sasha Levin <sashal(a)kernel.org> wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> arm64: fpsimd: Drop unneeded 'busy' flag
>
> to the 6.6-stable tree
Why?
> 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:
> arm64-fpsimd-drop-unneeded-busy-flag.patch
> and it can be found in the queue-6.6 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.
>
>
>
> commit 37f2773a1ef05374538d5e4ed26cbacebe363241
> Author: Ard Biesheuvel <ardb(a)kernel.org>
> Date: Fri Dec 8 12:32:20 2023 +0100
>
> arm64: fpsimd: Drop unneeded 'busy' flag
>
> [ Upstream commit 9b19700e623f96222c69ecb2adecb1a3e3664cc0 ]
>
> Kernel mode NEON will preserve the user mode FPSIMD state by saving it
> into the task struct before clobbering the registers. In order to avoid
> the need for preserving kernel mode state too, we disallow nested use of
> kernel mode NEON, i..e, use in softirq context while the interrupted
> task context was using kernel mode NEON too.
>
> Originally, this policy was implemented using a per-CPU flag which was
> exposed via may_use_simd(), requiring the users of the kernel mode NEON
> to deal with the possibility that it might return false, and having NEON
> and non-NEON code paths. This policy was changed by commit
> 13150149aa6ded1 ("arm64: fpsimd: run kernel mode NEON with softirqs
> disabled"), and now, softirq processing is disabled entirely instead,
> and so may_use_simd() can never fail when called from task or softirq
> context.
>
> This means we can drop the fpsimd_context_busy flag entirely, and
> instead, ensure that we disable softirq processing in places where we
> formerly relied on the flag for preventing races in the FPSIMD preserve
> routines.
>
> Signed-off-by: Ard Biesheuvel <ardb(a)kernel.org>
> Reviewed-by: Mark Brown <broonie(a)kernel.org>
> Tested-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
> Link: https://lore.kernel.org/r/20231208113218.3001940-7-ardb@google.com
> [will: Folded in fix from CAMj1kXFhzbJRyWHELCivQW1yJaF=p07LLtbuyXYX3G1WtsdyQg(a)mail.gmail.com]
> Signed-off-by: Will Deacon <will(a)kernel.org>
> Stable-dep-of: b8995a184170 ("Revert "arm64: fpsimd: Implement lazy restore for kernel mode FPSIMD"")
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/arch/arm64/include/asm/simd.h b/arch/arm64/include/asm/simd.h
> index 6a75d7ecdcaa2..8e86c9e70e483 100644
> --- a/arch/arm64/include/asm/simd.h
> +++ b/arch/arm64/include/asm/simd.h
> @@ -12,8 +12,6 @@
> #include <linux/preempt.h>
> #include <linux/types.h>
>
> -DECLARE_PER_CPU(bool, fpsimd_context_busy);
> -
> #ifdef CONFIG_KERNEL_MODE_NEON
>
> /*
> @@ -28,17 +26,10 @@ static __must_check inline bool may_use_simd(void)
> /*
> * We must make sure that the SVE has been initialized properly
> * before using the SIMD in kernel.
> - * fpsimd_context_busy is only set while preemption is disabled,
> - * and is clear whenever preemption is enabled. Since
> - * this_cpu_read() is atomic w.r.t. preemption, fpsimd_context_busy
> - * cannot change under our feet -- if it's set we cannot be
> - * migrated, and if it's clear we cannot be migrated to a CPU
> - * where it is set.
> */
> return !WARN_ON(!system_capabilities_finalized()) &&
> system_supports_fpsimd() &&
> - !in_hardirq() && !irqs_disabled() && !in_nmi() &&
> - !this_cpu_read(fpsimd_context_busy);
> + !in_hardirq() && !irqs_disabled() && !in_nmi();
> }
>
> #else /* ! CONFIG_KERNEL_MODE_NEON */
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 5cdfcc9e3e54b..b805bdab284c4 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -85,13 +85,13 @@
> * softirq kicks in. Upon vcpu_put(), KVM will save the vcpu FP state and
> * flag the register state as invalid.
> *
> - * In order to allow softirq handlers to use FPSIMD, kernel_neon_begin() may
> - * save the task's FPSIMD context back to task_struct from softirq context.
> - * To prevent this from racing with the manipulation of the task's FPSIMD state
> - * from task context and thereby corrupting the state, it is necessary to
> - * protect any manipulation of a task's fpsimd_state or TIF_FOREIGN_FPSTATE
> - * flag with {, __}get_cpu_fpsimd_context(). This will still allow softirqs to
> - * run but prevent them to use FPSIMD.
> + * In order to allow softirq handlers to use FPSIMD, kernel_neon_begin() may be
> + * called from softirq context, which will save the task's FPSIMD context back
> + * to task_struct. To prevent this from racing with the manipulation of the
> + * task's FPSIMD state from task context and thereby corrupting the state, it
> + * is necessary to protect any manipulation of a task's fpsimd_state or
> + * TIF_FOREIGN_FPSTATE flag with get_cpu_fpsimd_context(), which will suspend
> + * softirq servicing entirely until put_cpu_fpsimd_context() is called.
> *
> * For a certain task, the sequence may look something like this:
> * - the task gets scheduled in; if both the task's fpsimd_cpu field
> @@ -209,27 +209,14 @@ static inline void sme_free(struct task_struct *t) { }
>
> #endif
>
> -DEFINE_PER_CPU(bool, fpsimd_context_busy);
> -EXPORT_PER_CPU_SYMBOL(fpsimd_context_busy);
> -
> static void fpsimd_bind_task_to_cpu(void);
>
> -static void __get_cpu_fpsimd_context(void)
> -{
> - bool busy = __this_cpu_xchg(fpsimd_context_busy, true);
> -
> - WARN_ON(busy);
> -}
> -
> /*
> * Claim ownership of the CPU FPSIMD context for use by the calling context.
> *
> * The caller may freely manipulate the FPSIMD context metadata until
> * put_cpu_fpsimd_context() is called.
> *
> - * The double-underscore version must only be called if you know the task
> - * can't be preempted.
> - *
> * On RT kernels local_bh_disable() is not sufficient because it only
> * serializes soft interrupt related sections via a local lock, but stays
> * preemptible. Disabling preemption is the right choice here as bottom
> @@ -242,14 +229,6 @@ static void get_cpu_fpsimd_context(void)
> local_bh_disable();
> else
> preempt_disable();
> - __get_cpu_fpsimd_context();
> -}
> -
> -static void __put_cpu_fpsimd_context(void)
> -{
> - bool busy = __this_cpu_xchg(fpsimd_context_busy, false);
> -
> - WARN_ON(!busy); /* No matching get_cpu_fpsimd_context()? */
> }
>
> /*
> @@ -261,18 +240,12 @@ static void __put_cpu_fpsimd_context(void)
> */
> static void put_cpu_fpsimd_context(void)
> {
> - __put_cpu_fpsimd_context();
> if (!IS_ENABLED(CONFIG_PREEMPT_RT))
> local_bh_enable();
> else
> preempt_enable();
> }
>
> -static bool have_cpu_fpsimd_context(void)
> -{
> - return !preemptible() && __this_cpu_read(fpsimd_context_busy);
> -}
> -
> unsigned int task_get_vl(const struct task_struct *task, enum vec_type type)
> {
> return task->thread.vl[type];
> @@ -383,7 +356,7 @@ static void task_fpsimd_load(void)
> bool restore_ffr;
>
> WARN_ON(!system_supports_fpsimd());
> - WARN_ON(!have_cpu_fpsimd_context());
> + WARN_ON(preemptible());
>
> if (system_supports_sve() || system_supports_sme()) {
> switch (current->thread.fp_type) {
> @@ -467,7 +440,7 @@ static void fpsimd_save(void)
> unsigned int vl;
>
> WARN_ON(!system_supports_fpsimd());
> - WARN_ON(!have_cpu_fpsimd_context());
> + WARN_ON(preemptible());
>
> if (test_thread_flag(TIF_FOREIGN_FPSTATE))
> return;
> @@ -1583,7 +1556,7 @@ void fpsimd_thread_switch(struct task_struct *next)
> if (!system_supports_fpsimd())
> return;
>
> - __get_cpu_fpsimd_context();
> + WARN_ON_ONCE(!irqs_disabled());
>
> /* Save unsaved fpsimd state, if any: */
> fpsimd_save();
> @@ -1599,8 +1572,6 @@ void fpsimd_thread_switch(struct task_struct *next)
>
> update_tsk_thread_flag(next, TIF_FOREIGN_FPSTATE,
> wrong_task || wrong_cpu);
> -
> - __put_cpu_fpsimd_context();
> }
>
> static void fpsimd_flush_thread_vl(enum vec_type type)
> @@ -1892,13 +1863,15 @@ static void fpsimd_flush_cpu_state(void)
> */
> void fpsimd_save_and_flush_cpu_state(void)
> {
> + unsigned long flags;
> +
> if (!system_supports_fpsimd())
> return;
> WARN_ON(preemptible());
> - __get_cpu_fpsimd_context();
> + local_irq_save(flags);
> fpsimd_save();
> fpsimd_flush_cpu_state();
> - __put_cpu_fpsimd_context();
> + local_irq_restore(flags);
> }
>
> #ifdef CONFIG_KERNEL_MODE_NEON
I'm not seeing a test mail for v6.6.33-rc1 but it's in the stable-rc git
and I'm seeing build failures in the KVM selftests for arm64 with it:
/usr/bin/ld: /build/stage/build-work/kselftest/kvm/aarch64/vgic_init.o: in funct
ion `test_v2_uaccess_cpuif_no_vcpus':
/build/stage/linux/tools/testing/selftests/kvm/aarch64/vgic_init.c:388:(.text+0x
1234): undefined reference to `FIELD_PREP'
/usr/bin/ld: /build/stage/linux/tools/testing/selftests/kvm/aarch64/vgic_init.c:
388:(.text+0x1244): undefined reference to `FIELD_PREP'
/usr/bin/ld: /build/stage/linux/tools/testing/selftests/kvm/aarch64/vgic_init.c:
393:(.text+0x12a4): undefined reference to `FIELD_PREP'
/usr/bin/ld: /build/stage/linux/tools/testing/selftests/kvm/aarch64/vgic_init.c:
393:(.text+0x12b4): undefined reference to `FIELD_PREP'
/usr/bin/ld: /build/stage/linux/tools/testing/selftests/kvm/aarch64/vgic_init.c:
398:(.text+0x1308): undefined reference to `FIELD_PREP'
due to 12237178b318fb3 ("KVM: selftests: Add test for uaccesses to
non-existent vgic-v2 CPUIF") which was backported from
160933e330f4c5a13931d725a4d952a4b9aefa71.
commit 4a63bd179fa8d3fcc44a0d9d71d941ddd62f0c4e upstream.
Currently ALSA timer doesn't have the lower limit of the start tick
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
for hrtimer. Such a situation may lead to an unexpected RCU stall,
where the callback repeatedly queuing the expire update, as reported
by fuzzer.
This patch introduces a sanity check of the timer start tick time, so
that the system returns an error when a too small start size is set.
As of this patch, the lower limit is hard-coded to 100us, which is
small enough but can still work somehow.
[ backport note: the error handling is changed, as the original commit
is based on the recent cleanup with guard() in commit beb45974dd49
-- tiwai ]
Reported-by: syzbot+43120c2af6ca2938cc38(a)syzkaller.appspotmail.com
Closes: https://lore.kernel.org/r/000000000000fa00a1061740ab6d@google.com
Cc: <stable(a)vger.kernel.org>
Link: https://lore.kernel.org/r/20240514182745.4015-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
---
Greg, this is an alternative fix to the original cherry-pick; apply
to 6.8.y and older stable kernels. Thanks!
sound/core/timer.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/sound/core/timer.c b/sound/core/timer.c
index e6e551d4a29e..a0b515981ee9 100644
--- a/sound/core/timer.c
+++ b/sound/core/timer.c
@@ -553,6 +553,16 @@ static int snd_timer_start1(struct snd_timer_instance *timeri,
goto unlock;
}
+ /* check the actual time for the start tick;
+ * bail out as error if it's way too low (< 100us)
+ */
+ if (start) {
+ if ((u64)snd_timer_hw_resolution(timer) * ticks < 100000) {
+ result = -EINVAL;
+ goto unlock;
+ }
+ }
+
if (start)
timeri->ticks = timeri->cticks = ticks;
else if (!timeri->cticks)
--
2.43.0
No upstream commit exists for this commit.
The issue was introduced with commit e2f744a82d72 ("clk: mediatek:
Add MT2712 clock support")
In case of memory allocation fail in clk_mt2712_top_init_early()
'top_clk_data' will be set to NULL and later dereferenced without check.
Fix this bug by adding NULL-return check.
Upstream branch code has been significantly refactored and can't be
backported directly.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru>
---
drivers/clk/mediatek/clk-mt2712.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mt2712.c b/drivers/clk/mediatek/clk-mt2712.c
index a0f0c9ed48d1..1830bae661dc 100644
--- a/drivers/clk/mediatek/clk-mt2712.c
+++ b/drivers/clk/mediatek/clk-mt2712.c
@@ -1277,6 +1277,11 @@ static void clk_mt2712_top_init_early(struct device_node *node)
if (!top_clk_data) {
top_clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
+ if (!top_clk_data) {
+ pr_err("%s(): could not register clock provider: %d\n",
+ __func__, -ENOMEM);
+ return;
+ }
for (i = 0; i < CLK_TOP_NR_CLK; i++)
top_clk_data->hws[i] = ERR_PTR(-EPROBE_DEFER);
--
2.30.2
No upstream commit exists for this commit.
The issue was introduced with commit c93d059a8045 ("clk: mediatek: mt8183:
Register 13MHz clock earlier for clocksource")
In case of memory allocation fail in clk_mt8183_top_init_early()
'top_clk_data' will be set to NULL and later dereferenced without check.
Fix this bug by adding NULL-return check.
Upstream branch code has been significantly refactored and can't be
backported directly.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru>
---
drivers/clk/mediatek/clk-mt8183.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mt8183.c b/drivers/clk/mediatek/clk-mt8183.c
index 78620244144e..8377a877d9e3 100644
--- a/drivers/clk/mediatek/clk-mt8183.c
+++ b/drivers/clk/mediatek/clk-mt8183.c
@@ -1185,6 +1185,11 @@ static void clk_mt8183_top_init_early(struct device_node *node)
int i;
top_clk_data = mtk_alloc_clk_data(CLK_TOP_NR_CLK);
+ if (!top_clk_data) {
+ pr_err("%s(): could not register clock provider: %d\n",
+ __func__, -ENOMEM);
+ return;
+ }
for (i = 0; i < CLK_TOP_NR_CLK; i++)
top_clk_data->hws[i] = ERR_PTR(-EPROBE_DEFER);
--
2.30.2
[ Upstream commit 1cd4bc987abb2823836cbb8f887026011ccddc8a ]
Commit f58f45c1e5b9 ("vxlan: drop packets from invalid src-address")
has recently been added to vxlan mainly in the context of source
address snooping/learning so that when it is enabled, an entry in the
FDB is not being created for an invalid address for the corresponding
tunnel endpoint.
Before commit f58f45c1e5b9 vxlan was similarly behaving as geneve in
that it passed through whichever macs were set in the L2 header. It
turns out that this change in behavior breaks setups, for example,
Cilium with netkit in L3 mode for Pods as well as tunnel mode has been
passing before the change in f58f45c1e5b9 for both vxlan and geneve.
After mentioned change it is only passing for geneve as in case of
vxlan packets are dropped due to vxlan_set_mac() returning false as
source and destination macs are zero which for E/W traffic via tunnel
is totally fine.
Fix it by only opting into the is_valid_ether_addr() check in
vxlan_set_mac() when in fact source address snooping/learning is
actually enabled in vxlan. This is done by moving the check into
vxlan_snoop(). With this change, the Cilium connectivity test suite
passes again for both tunnel flavors.
Fixes: f58f45c1e5b9 ("vxlan: drop packets from invalid src-address")
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Cc: David Bauer <mail(a)david-bauer.net>
Cc: Ido Schimmel <idosch(a)nvidia.com>
Cc: Nikolay Aleksandrov <razor(a)blackwall.org>
Cc: Martin KaFai Lau <martin.lau(a)kernel.org>
Reviewed-by: Ido Schimmel <idosch(a)nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor(a)blackwall.org>
Reviewed-by: David Bauer <mail(a)david-bauer.net>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
---
drivers/net/vxlan/vxlan_core.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
index 3a9148fb1422..eccf09c81df2 100644
--- a/drivers/net/vxlan/vxlan_core.c
+++ b/drivers/net/vxlan/vxlan_core.c
@@ -1446,6 +1446,10 @@ static bool vxlan_snoop(struct net_device *dev,
struct vxlan_fdb *f;
u32 ifindex = 0;
+ /* Ignore packets from invalid src-address */
+ if (!is_valid_ether_addr(src_mac))
+ return true;
+
#if IS_ENABLED(CONFIG_IPV6)
if (src_ip->sa.sa_family == AF_INET6 &&
(ipv6_addr_type(&src_ip->sin6.sin6_addr) & IPV6_ADDR_LINKLOCAL))
@@ -1615,10 +1619,6 @@ static bool vxlan_set_mac(struct vxlan_dev *vxlan,
if (ether_addr_equal(eth_hdr(skb)->h_source, vxlan->dev->dev_addr))
return false;
- /* Ignore packets from invalid src-address */
- if (!is_valid_ether_addr(eth_hdr(skb)->h_source))
- return false;
-
/* Get address from the outer IP header */
if (vxlan_get_sk_family(vs) == AF_INET) {
saddr.sin.sin_addr.s_addr = ip_hdr(skb)->saddr;
--
2.34.1