The open() function returns -1 on error. openat() and open() initialize
'from' and 'to', and only 'from' validated with 'if' statement. If the
initialization of variable 'to' fails, we should better check the value
of 'to' and close 'from' to avoid possible file leak. Improve the checking
of 'from' additionally.
Fixes: 32ae976ed3b5 ("selftests/capabilities: Add tests for capability evolution")
Signed-off-by: Ma Ke <make24(a)iscas.ac.cn>
---
Changes in v2:
- modified the patch according to suggestions;
- found by customized static analysis tool.
---
tools/testing/selftests/capabilities/test_execve.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/capabilities/test_execve.c b/tools/testing/selftests/capabilities/test_execve.c
index 47bad7ddc5bc..6406ab6aa1f5 100644
--- a/tools/testing/selftests/capabilities/test_execve.c
+++ b/tools/testing/selftests/capabilities/test_execve.c
@@ -145,10 +145,14 @@ static void chdir_to_tmpfs(void)
static void copy_fromat_to(int fromfd, const char *fromname, const char *toname)
{
int from = openat(fromfd, fromname, O_RDONLY);
- if (from == -1)
+ if (from < 0)
ksft_exit_fail_msg("open copy source - %s\n", strerror(errno));
int to = open(toname, O_CREAT | O_WRONLY | O_EXCL, 0700);
+ if (to < 0) {
+ close(from);
+ ksft_exit_fail_msg("open copy destination - %s\n", strerror(errno));
+ }
while (true) {
char buf[4096];
--
2.25.1
This patch series is motivated by the following observation:
Raise a signal, jump to signal handler. The ucontext_t structure dumped
by kernel to userspace has a uc_sigmask field having the mask of blocked
signals. If you run a fresh minimalistic program doing this, this field
is empty, even if you block some signals while registering the handler
with sigaction().
Here is what the man-pages have to say:
sigaction(2): "sa_mask specifies a mask of signals which should be blocked
(i.e., added to the signal mask of the thread in which the signal handler
is invoked) during execution of the signal handler. In addition, the
signal which triggered the handler will be blocked, unless the SA_NODEFER
flag is used."
signal(7): Under "Execution of signal handlers", (1.3) implies:
"The thread's current signal mask is accessible via the ucontext_t
object that is pointed to by the third argument of the signal handler."
But, (1.4) states:
"Any signals specified in act->sa_mask when registering the handler with
sigprocmask(2) are added to the thread's signal mask. The signal being
delivered is also added to the signal mask, unless SA_NODEFER was
specified when registering the handler. These signals are thus blocked
while the handler executes."
There clearly is no distinction being made in the man pages between
"Thread's signal mask" and ucontext_t; this logically should imply
that a signal blocked by populating struct sigaction should be visible
in ucontext_t.
Here is what the kernel code does (for Aarch64):
do_signal() -> handle_signal() -> sigmask_to_save(), which returns
¤t->blocked, is passed to setup_rt_frame() -> setup_sigframe() ->
__copy_to_user(). Hence, ¤t->blocked is copied to ucontext_t
exposed to userspace. Returning back to handle_signal(),
signal_setup_done() -> signal_delivered() -> sigorsets() and
set_current_blocked() are responsible for using information from
struct ksignal ksig, which was populated through the sigaction()
system call in kernel/signal.c:
copy_from_user(&new_sa.sa, act, sizeof(new_sa.sa)),
to update ¤t->blocked; hence, the set of blocked signals for the
current thread is updated AFTER the kernel dumps ucontext_t to
userspace.
Assuming that the above is indeed the intended behaviour, because it
semantically makes sense, since the signals blocked using sigaction()
remain blocked only till the execution of the handler, and not in the
context present before jumping to the handler (but nothing can be
confirmed from the man-pages), the series introduces a test for
mangling with uc_sigmask. I will send a separate series to fix the
man-pages.
The proposed selftest has been tested out on Aarch32, Aarch64 and x86_64.
v3->v4:
- Allocate sigsets as automatic variables to avoid malloc()
v2->v3:
- ucontext describes current state -> ucontext describes interrupted context
- Add a comment for blockage of USR2 even after return from handler
- Describe blockage of signals in a better way
v1->v2:
- Replace all occurrences of SIGPIPE with SIGSEGV
- Fixed a mismatch between code comment and ksft log
- Add a testcase: Raise the same signal again; it must not be queued
- Remove unneeded <assert.h>, <unistd.h>
- Give a detailed test description in the comments; also describe the
exact meaning of delivered and blocked
- Handle errors for all libc functions/syscalls
- Mention tests in Makefile and .gitignore in alphabetical order
v1:
- https://lore.kernel.org/all/20240607122319.768640-1-dev.jain@arm.com/
Dev Jain (2):
selftests: Rename sigaltstack to generic signal
selftests: Add a test mangling with uc_sigmask
tools/testing/selftests/Makefile | 2 +-
.../{sigaltstack => signal}/.gitignore | 3 +-
.../{sigaltstack => signal}/Makefile | 3 +-
.../current_stack_pointer.h | 0
.../selftests/signal/mangle_uc_sigmask.c | 186 ++++++++++++++++++
.../sas.c => signal/sigaltstack.c} | 0
6 files changed, 191 insertions(+), 3 deletions(-)
rename tools/testing/selftests/{sigaltstack => signal}/.gitignore (57%)
rename tools/testing/selftests/{sigaltstack => signal}/Makefile (53%)
rename tools/testing/selftests/{sigaltstack => signal}/current_stack_pointer.h (100%)
create mode 100644 tools/testing/selftests/signal/mangle_uc_sigmask.c
rename tools/testing/selftests/{sigaltstack/sas.c => signal/sigaltstack.c} (100%)
--
2.34.1
In the same way than commit ae7487d112cf ("selftests/hid: ensure we can
compile the tests on kernels pre-6.3") we should expose struct hid_bpf_ops
when it's not available in vmlinux.h.
So unexpose an eventual struct hid_bpf_ops, include vmlinux.h, and
re-export struct hid_bpf_ops.
Fixes: d7696738d66b ("selftests/hid: convert the hid_bpf selftests with struct_ops")
Reported-by: kernel test robot <lkp(a)intel.com>
Closes: https://lore.kernel.org/r/202406270328.bscLN1IF-lkp@intel.com/
Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org>
---
Same situation than in an early report when HID-BPF was initially
included: the automatically generated vmlinux.h doesn't contain all of
the required structs and the compilation of the bpf program fails.
---
tools/testing/selftests/hid/progs/hid_bpf_helpers.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
index c72e44321764..5a911f0e8625 100644
--- a/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
+++ b/tools/testing/selftests/hid/progs/hid_bpf_helpers.h
@@ -7,6 +7,7 @@
/* "undefine" structs and enums in vmlinux.h, because we "override" them below */
#define hid_bpf_ctx hid_bpf_ctx___not_used
+#define hid_bpf_ops hid_bpf_ops___not_used
#define hid_report_type hid_report_type___not_used
#define hid_class_request hid_class_request___not_used
#define hid_bpf_attach_flags hid_bpf_attach_flags___not_used
@@ -24,6 +25,7 @@
#include "vmlinux.h"
#undef hid_bpf_ctx
+#undef hid_bpf_ops
#undef hid_report_type
#undef hid_class_request
#undef hid_bpf_attach_flags
@@ -68,6 +70,20 @@ enum hid_class_request {
HID_REQ_SET_PROTOCOL = 0x0B,
};
+struct hid_bpf_ops {
+ int hid_id;
+ u32 flags;
+ struct list_head list;
+ int (*hid_device_event)(struct hid_bpf_ctx *ctx, enum hid_report_type report_type,
+ __u64 source);
+ int (*hid_rdesc_fixup)(struct hid_bpf_ctx *ctx);
+ int (*hid_hw_request)(struct hid_bpf_ctx *ctx, unsigned char reportnum,
+ enum hid_report_type rtype, enum hid_class_request reqtype,
+ __u64 source);
+ int (*hid_hw_output_report)(struct hid_bpf_ctx *ctx, __u64 source);
+ struct hid_device *hdev;
+};
+
#ifndef BPF_F_BEFORE
#define BPF_F_BEFORE (1U << 3)
#endif
---
base-commit: d3e15189bfd4d0a9d3a7ad8bd0e6ebb1c0419f93
change-id: 20240627-fix-cki-f372855cbf6f
Best regards,
--
Benjamin Tissoires <bentiss(a)kernel.org>
This series is a followup of the struct_ops conversion.
Therefore, it is based on top of the for-6.11/bpf branch of the hid.git
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/log/?h=for-6.11…
The first patch should go in ASAP, it's a fix that was detected by Dan
and which is actually breaking some use cases.
The rest is adding new capabilities to HID-BPF: being able to intercept
hid_hw_raw_request() and hid_hw_ouptut_report(). Both operations are
write operations to the device.
Having those new hooks allows to implement the "firewall" of HID
devices: this way a bpf program can selectively authorize an hidraw
client to write or not to the device depending on what is requested.
This also allows to completely emulate new behavior: we can now create a
"fake" feature on a HID device, and when we receive a request on this
feature, we can emulate the answer by either statically answering or
even by communicating with the device from bpf, as those new hooks are
sleepable.
Last, there is one change in the kfunc hid_bpf_input_report, in which it
actually waits for the device to be ready. This will not break any
potential users as the function was already declared as sleepable.
Cheers,
Benjamin
Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org>
---
Changes in v2:
- made use of srcu, for sleepable users
- Link to v1: https://lore.kernel.org/r/20240621-hid_hw_req_bpf-v1-0-d7ab8b885a0b@kernel.…
---
Benjamin Tissoires (13):
HID: bpf: fix dispatch_hid_bpf_device_event uninitialized ret value
HID: add source argument to HID low level functions
HID: bpf: protect HID-BPF prog_list access by a SRCU
HID: bpf: add HID-BPF hooks for hid_hw_raw_requests
HID: bpf: prevent infinite recursions with hid_hw_raw_requests hooks
selftests/hid: add tests for hid_hw_raw_request HID-BPF hooks
HID: bpf: add HID-BPF hooks for hid_hw_output_report
selftests/hid: add tests for hid_hw_output_report HID-BPF hooks
HID: bpf: make hid_bpf_input_report() sleep until the device is ready
selftests/hid: add wq test for hid_bpf_input_report()
HID: bpf: allow hid_device_event hooks to inject input reports on self
selftests/hid: add another test for injecting an event from an event hook
selftests/hid: add an infinite loop test for hid_bpf_try_input_report
Documentation/hid/hid-bpf.rst | 2 +-
drivers/hid/bpf/hid_bpf_dispatch.c | 165 ++++++++++-
drivers/hid/bpf/hid_bpf_dispatch.h | 1 +
drivers/hid/bpf/hid_bpf_struct_ops.c | 6 +-
drivers/hid/hid-core.c | 118 +++++---
drivers/hid/hidraw.c | 10 +-
include/linux/hid.h | 7 +
include/linux/hid_bpf.h | 80 ++++-
tools/testing/selftests/hid/hid_bpf.c | 326 +++++++++++++++++++++
tools/testing/selftests/hid/progs/hid.c | 292 ++++++++++++++++++
.../testing/selftests/hid/progs/hid_bpf_helpers.h | 13 +
11 files changed, 955 insertions(+), 65 deletions(-)
---
base-commit: 33c0fb85b571b0f1bbdbf466e770eebeb29e6f41
change-id: 20240614-hid_hw_req_bpf-df0b95aeb425
Best regards,
--
Benjamin Tissoires <bentiss(a)kernel.org>
** Background **
Currently, OVS supports several packet sampling mechanisms (sFlow,
per-bridge IPFIX, per-flow IPFIX). These end up being translated into a
userspace action that needs to be handled by ovs-vswitchd's handler
threads only to be forwarded to some third party application that
will somehow process the sample and provide observability on the
datapath.
A particularly interesting use-case is controller-driven
per-flow IPFIX sampling where the OpenFlow controller can add metadata
to samples (via two 32bit integers) and this metadata is then available
to the sample-collecting system for correlation.
** Problem **
The fact that sampled traffic share netlink sockets and handler thread
time with upcalls, apart from being a performance bottleneck in the
sample extraction itself, can severely compromise the datapath,
yielding this solution unfit for highly loaded production systems.
Users are left with little options other than guessing what sampling
rate will be OK for their traffic pattern and system load and dealing
with the lost accuracy.
Looking at available infrastructure, an obvious candidated would be
to use psample. However, it's current state does not help with the
use-case at stake because sampled packets do not contain user-defined
metadata.
** Proposal **
This series is an attempt to fix this situation by extending the
existing psample infrastructure to carry a variable length
user-defined cookie.
The main existing user of psample is tc's act_sample. It is also
extended to forward the action's cookie to psample.
Finally, a new OVS action (OVS_SAMPLE_ATTR_EMIT_SAMPLE) is created.
It accepts a group and an optional cookie and uses psample to
multicast the packet and the metadata.
--
v4 -> v5:
- Rebased.
- Removed lefover enum value and wrapped some long lines in selftests.
v3 -> v4:
- Rebased.
- Addressed Jakub's comment on private and unused nla attributes.
v2 -> v3:
- Addressed comments from Simon, Aaron and Ilya.
- Dropped probability propagation in nested sample actions.
- Dropped patch v2's 7/9 in favor of a userspace implementation and
consume skb if emit_sample is the last action, same as we do with
userspace.
- Split ovs-dpctl.py features in independent patches.
v1 -> v2:
- Create a new action ("emit_sample") rather than reuse existing
"sample" one.
- Add probability semantics to psample's sampling rate.
- Store sampling probability in skb's cb area and use it in emit_sample.
- Test combining "emit_sample" with "trunc"
- Drop group_id filtering and tracepoint in psample.
rfc_v2 -> v1:
- Accommodate Ilya's comments.
- Split OVS's attribute in two attributes and simplify internal
handling of psample arguments.
- Extend psample and tc with a user-defined cookie.
- Add a tracepoint to psample to facilitate troubleshooting.
rfc_v1 -> rfc_v2:
- Use psample instead of a new OVS-only multicast group.
- Extend psample and tc with a user-defined cookie.
Adrian Moreno (10):
net: psample: add user cookie
net: sched: act_sample: add action cookie to sample
net: psample: skip packet copy if no listeners
net: psample: allow using rate as probability
net: openvswitch: add emit_sample action
net: openvswitch: store sampling probability in cb.
selftests: openvswitch: add emit_sample action
selftests: openvswitch: add userspace parsing
selftests: openvswitch: parse trunc action
selftests: openvswitch: add emit_sample test
Documentation/netlink/specs/ovs_flow.yaml | 17 ++
include/net/psample.h | 5 +-
include/uapi/linux/openvswitch.h | 31 +-
include/uapi/linux/psample.h | 11 +-
net/openvswitch/Kconfig | 1 +
net/openvswitch/actions.c | 63 +++-
net/openvswitch/datapath.h | 3 +
net/openvswitch/flow_netlink.c | 33 ++-
net/openvswitch/vport.c | 1 +
net/psample/psample.c | 16 +-
net/sched/act_sample.c | 12 +
.../selftests/net/openvswitch/openvswitch.sh | 114 +++++++-
.../selftests/net/openvswitch/ovs-dpctl.py | 272 +++++++++++++++++-
13 files changed, 563 insertions(+), 16 deletions(-)
--
2.45.1
From: Geliang Tang <tanggeliang(a)kylinos.cn>
v2:
- add patch 2, a new fix for sk_msg_memcopy_from_iter.
- update patch 3, only test "sk->sk_prot->close" as Eric suggested.
- update patch 4, use "goto err" instead of "return" as Eduard
suggested.
- add "fixes" tag for patch 1-3.
- change subject prefixes as "bpf-next" to trigger BPF CI.
- cc Loongarch maintainers too.
BPF selftests seem to have not been fully tested on Loongarch. When I
ran these tests on Loongarch recently, some errors occur. This patch set
contains some null-check related fixes for these errors.
Geliang Tang (4):
skmsg: null check for sg_page in sk_msg_recvmsg
skmsg: null check for sg_page in sk_msg_memcopy_from_iter
inet: null check for close in inet_release
selftests/bpf: Null checks for link in bpf_tcp_ca
net/core/skmsg.c | 4 ++++
net/ipv4/af_inet.c | 3 ++-
.../selftests/bpf/prog_tests/bpf_tcp_ca.c | 16 ++++++++++++----
3 files changed, 18 insertions(+), 5 deletions(-)
--
2.43.0