When arm64 signal context data overflows the base struct sigcontext it gets
placed in an extra buffer pointed to by a record of type EXTRA_CONTEXT in
the base struct sigcontext which is required to be the last record in the
base struct sigframe. The current validation code attempts to check this
by using GET_RESV_NEXT_HEAD() to step forward from the current record to
the next but that is a macro which assumes it is being provided with a
struct _aarch64_ctx and uses the size there to skip forward to the next
record. Instead validate_extra_context() passes it a struct extra_context
which has a separate size field. This compiles but results in us trying
to validate a terminator in completely the wrong place, at best failing
validation and at worst just segfaulting. Fix this by passing the struct
_aarch64_ctx we meant to into the macro.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/signal/testcases/testcases.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/arm64/signal/testcases/testcases.c b/tools/testing/selftests/arm64/signal/testcases/testcases.c
index 84c36bee4d82..d98828cb542b 100644
--- a/tools/testing/selftests/arm64/signal/testcases/testcases.c
+++ b/tools/testing/selftests/arm64/signal/testcases/testcases.c
@@ -33,7 +33,7 @@ bool validate_extra_context(struct extra_context *extra, char **err)
return false;
fprintf(stderr, "Validating EXTRA...\n");
- term = GET_RESV_NEXT_HEAD(extra);
+ term = GET_RESV_NEXT_HEAD(&extra->head);
if (!term || term->magic || term->size) {
*err = "Missing terminator after EXTRA context";
return false;
--
2.30.2
The default file permissions on a memfd include execute bits, which
means that such a memfd can be filled with a executable and passed to
the exec() family of functions. This is undesirable on systems where all
code is verified and all filesystems are intended to be mounted noexec,
since an attacker may be able to use a memfd to load unverified code and
execute it.
Additionally, execution via memfd is a common way to avoid scrutiny for
malicious code, since it allows execution of a program without a file
ever appearing on disk. This attack vector is not totally mitigated with
this new flag, since the default memfd file permissions must remain
executable to avoid breaking existing legitimate uses, but it should be
possible to use other security mechanisms to prevent memfd_create calls
without MFD_NOEXEC on systems where it is known that executable memfds
are not necessary.
This patch series adds a new MFD_NOEXEC flag for memfd_create(), which
allows creation of non-executable memfds, and as part of the
implementation of this new flag, it also adds a new F_SEAL_EXEC seal,
which will prevent modification of any of the execute bits of a sealed
memfd.
I am not sure if this is the best way to implement the desired behavior
(for example, the F_SEAL_EXEC seal is really more of an implementation
detail and feels a bit clunky to expose), so suggestions are welcome
for alternate approaches.
Daniel Verkamp (4):
mm/memfd: add F_SEAL_EXEC
mm/memfd: add MFD_NOEXEC flag to memfd_create
selftests/memfd: add tests for F_SEAL_EXEC
selftests/memfd: add tests for MFD_NOEXEC
include/uapi/linux/fcntl.h | 1 +
include/uapi/linux/memfd.h | 1 +
mm/memfd.c | 12 ++-
mm/shmem.c | 6 ++
tools/testing/selftests/memfd/memfd_test.c | 114 +++++++++++++++++++++
5 files changed, 133 insertions(+), 1 deletion(-)
--
2.35.1.1094.g7c7d902a7c-goog
This patchset adds support for SRv6 Headend behavior with Reduced
Encapsulation. It introduces the H.Encaps.Red and H.L2Encaps.Red versions
of the SRv6 H.Encaps and H.L2Encaps behaviors, according to RFC 8986 [1].
In details, the patchset is made of:
- patch 1/4: add support for SRv6 H.Encaps.Red behavior;
- Patch 2/4: add support for SRv6 H.L2Encaps.Red behavior;
- patch 2/4: add selftest for SRv6 H.Encaps.Red behavior;
- patch 3/4: add selftest for SRv6 H.L2Encaps.Red behavior.
The corresponding iproute2 patch for supporting SRv6 H.Encaps.Red and
H.L2Encaps.Red behaviors is provided in a separated patchset.
[1] - https://datatracker.ietf.org/doc/html/rfc8986
V4 -> v5:
- Fix skb checksum for SRH Reduced encapsulation/insertion;
- Improve selftests by:
i) adding a random suffix to network namespaces;
ii) creating net devices directly into network namespaces;
iii) using trap EXIT command to properly clean up selftest networks.
Thanks to Paolo Abeni.
v3 -> v4:
- Add selftests to the Makefile, thanks to Jakub Kicinski.
v2 -> v3:
- Keep SRH when HMAC TLV is present;
- Split the support for H.Encaps.Red and H.L2Encaps.Red behaviors in two
patches (respectively, patch 1/4 and patch 2/4);
- Add selftests for SRv6 H.Encaps.Red and H.L2Encaps.Red.
v1 -> v2:
- Fixed sparse warnings;
- memset now uses sizeof() instead of hardcoded value;
- Removed EXPORT_SYMBOL_GPL.
Andrea Mayer (4):
seg6: add support for SRv6 H.Encaps.Red behavior
seg6: add support for SRv6 H.L2Encaps.Red behavior
selftests: seg6: add selftest for SRv6 H.Encaps.Red behavior
selftests: seg6: add selftest for SRv6 H.L2Encaps.Red behavior
include/uapi/linux/seg6_iptunnel.h | 2 +
net/ipv6/seg6_iptunnel.c | 140 ++-
tools/testing/selftests/net/Makefile | 2 +
.../net/srv6_hencap_red_l3vpn_test.sh | 879 ++++++++++++++++++
.../net/srv6_hl2encap_red_l2vpn_test.sh | 821 ++++++++++++++++
5 files changed, 1842 insertions(+), 2 deletions(-)
create mode 100755 tools/testing/selftests/net/srv6_hencap_red_l3vpn_test.sh
create mode 100755 tools/testing/selftests/net/srv6_hl2encap_red_l2vpn_test.sh
--
2.20.1
Add a Makefile which takes care of installing the selftests in
tools/testing/selftests/drivers/net/dsa. This can be used to install all
DSA specific selftests and forwarding.config using the same approach as
for the selftests in tools/testing/selftests/net/forwarding.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl(a)googlemail.com>
---
.../testing/selftests/drivers/net/dsa/Makefile | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 tools/testing/selftests/drivers/net/dsa/Makefile
diff --git a/tools/testing/selftests/drivers/net/dsa/Makefile b/tools/testing/selftests/drivers/net/dsa/Makefile
new file mode 100644
index 000000000000..2a731d5c6d85
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/dsa/Makefile
@@ -0,0 +1,17 @@
+# SPDX-License-Identifier: GPL-2.0+ OR MIT
+
+TEST_PROGS = bridge_locked_port.sh \
+ bridge_mdb.sh \
+ bridge_mld.sh \
+ bridge_vlan_aware.sh \
+ bridge_vlan_mcast.sh \
+ bridge_vlan_unaware.sh \
+ local_termination.sh \
+ no_forwarding.sh \
+ test_bridge_fdb_stress.sh
+
+TEST_PROGS_EXTENDED := lib.sh
+
+TEST_FILES := forwarding.config
+
+include ../../../lib.mk
--
2.37.1
On Thu, Jun 30, 2022 at 01:16:34PM +0200, Hans Schultz wrote:
> This patch is related to the patch set
> "Add support for locked bridge ports (for 802.1X)"
> Link: https://lore.kernel.org/netdev/20220223101650.1212814-1-schultz.hans+netdev…
>
> This patch makes the locked port feature work with learning turned on,
> which is enabled with the command:
>
> bridge link set dev DEV learning on
>
> Without this patch, link local traffic (01:80:c2) like EAPOL packets will
> create a fdb entry when ingressing on a locked port with learning turned
> on, thus unintentionally opening up the port for traffic for the said MAC.
>
> Some switchcore features like Mac-Auth and refreshing of FDB entries,
> require learning enables on some switchcores, f.ex. the mv88e6xxx family.
> Other features may apply too.
>
> Since many switchcores trap or mirror various multicast packets to the
> CPU, link local traffic will unintentionally unlock the port for the
> SA mac in question unless prevented by this patch.
Why not just teach hostapd to do:
echo 1 > /sys/class/net/br0/bridge/no_linklocal_learn
?