Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
bpf: Make KF_TRUSTED_ARGS the default for all kfuncs
Change the verifier to make trusted args the default requirement for
all kfuncs by removing is_kfunc_trusted_args() assuming it be to always
return true.
This works because:
1. Context pointers (xdp_md, __sk_buff, etc.) are handled through their
own KF_ARG_PTR_TO_CTX case label and bypass the trusted check
2. Struct_ops callback arguments are already marked as PTR_TRUSTED during
initialization and pass is_trusted_reg()
3. KF_RCU kfuncs are handled separately via is_kfunc_rcu() checks at
call sites (always checked with || alongside is_kfunc_trusted_args)
This simple change makes all kfuncs require trusted args by default
while maintaining correct behavior for all existing special cases.
Note: This change means kfuncs that previously accepted NULL pointers
without KF_TRUSTED_ARGS will now reject NULL at verification time.
Several netfilter kfuncs are affected: bpf_xdp_ct_lookup(),
bpf_skb_ct_lookup(), bpf_xdp_ct_alloc(), and bpf_skb_ct_alloc() all
accept NULL for their bpf_tuple and opts parameters internally (checked
in __bpf_nf_ct_lookup), but after this change the verifier rejects NULL
before the kfunc is even called. This is acceptable because these kfuncs
don't work with NULL parameters in their proper usage. Now they will be
rejected rather than returning an error, which shouldn't make a
difference to BPF programs that were using these kfuncs properly.
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Puranjay Mohan <puranjay@kernel.org>
Link: https://lore.kernel.org/r/20260102180038.2708325-2-puranjay@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
authored by
Puranjay Mohan
and committed by
Alexei Starovoitov
1a5c01d2
c286e7e9
+220
-234
+214
-216
Documentation/bpf/kfuncs.rst
+214
-216
Documentation/bpf/kfuncs.rst
···
50
50
kfunc. Otherwise one may directly make the kfunc visible to the BPF program by
51
51
registering it with the BPF subsystem. See :ref:`BPF_kfunc_nodef`.
52
52
53
-
2.2 Annotating kfunc parameters
54
-
-------------------------------
55
-
56
-
Similar to BPF helpers, there is sometime need for additional context required
57
-
by the verifier to make the usage of kernel functions safer and more useful.
58
-
Hence, we can annotate a parameter by suffixing the name of the argument of the
59
-
kfunc with a __tag, where tag may be one of the supported annotations.
60
-
61
-
2.2.1 __sz Annotation
62
-
---------------------
63
-
64
-
This annotation is used to indicate a memory and size pair in the argument list.
65
-
An example is given below::
66
-
67
-
__bpf_kfunc void bpf_memzero(void *mem, int mem__sz)
68
-
{
69
-
...
70
-
}
71
-
72
-
Here, the verifier will treat first argument as a PTR_TO_MEM, and second
73
-
argument as its size. By default, without __sz annotation, the size of the type
74
-
of the pointer is used. Without __sz annotation, a kfunc cannot accept a void
75
-
pointer.
76
-
77
-
2.2.2 __k Annotation
53
+
2.2 kfunc Parameters
78
54
--------------------
79
55
80
-
This annotation is only understood for scalar arguments, where it indicates that
81
-
the verifier must check the scalar argument to be a known constant, which does
82
-
not indicate a size parameter, and the value of the constant is relevant to the
83
-
safety of the program.
56
+
All kfuncs now require trusted arguments by default. This means that all
57
+
pointer arguments must be valid, and all pointers to BTF objects must be
58
+
passed in their unmodified form (at a zero offset, and without having been
59
+
obtained from walking another pointer, with exceptions described below).
84
60
85
-
An example is given below::
86
-
87
-
__bpf_kfunc void *bpf_obj_new(u32 local_type_id__k, ...)
88
-
{
89
-
...
90
-
}
91
-
92
-
Here, bpf_obj_new uses local_type_id argument to find out the size of that type
93
-
ID in program's BTF and return a sized pointer to it. Each type ID will have a
94
-
distinct size, hence it is crucial to treat each such call as distinct when
95
-
values don't match during verifier state pruning checks.
96
-
97
-
Hence, whenever a constant scalar argument is accepted by a kfunc which is not a
98
-
size parameter, and the value of the constant matters for program safety, __k
99
-
suffix should be used.
100
-
101
-
2.2.3 __uninit Annotation
102
-
-------------------------
103
-
104
-
This annotation is used to indicate that the argument will be treated as
105
-
uninitialized.
106
-
107
-
An example is given below::
108
-
109
-
__bpf_kfunc int bpf_dynptr_from_skb(..., struct bpf_dynptr_kern *ptr__uninit)
110
-
{
111
-
...
112
-
}
113
-
114
-
Here, the dynptr will be treated as an uninitialized dynptr. Without this
115
-
annotation, the verifier will reject the program if the dynptr passed in is
116
-
not initialized.
117
-
118
-
2.2.4 __opt Annotation
119
-
-------------------------
120
-
121
-
This annotation is used to indicate that the buffer associated with an __sz or __szk
122
-
argument may be null. If the function is passed a nullptr in place of the buffer,
123
-
the verifier will not check that length is appropriate for the buffer. The kfunc is
124
-
responsible for checking if this buffer is null before using it.
125
-
126
-
An example is given below::
127
-
128
-
__bpf_kfunc void *bpf_dynptr_slice(..., void *buffer__opt, u32 buffer__szk)
129
-
{
130
-
...
131
-
}
132
-
133
-
Here, the buffer may be null. If buffer is not null, it at least of size buffer_szk.
134
-
Either way, the returned buffer is either NULL, or of size buffer_szk. Without this
135
-
annotation, the verifier will reject the program if a null pointer is passed in with
136
-
a nonzero size.
137
-
138
-
2.2.5 __str Annotation
139
-
----------------------------
140
-
This annotation is used to indicate that the argument is a constant string.
141
-
142
-
An example is given below::
143
-
144
-
__bpf_kfunc bpf_get_file_xattr(..., const char *name__str, ...)
145
-
{
146
-
...
147
-
}
148
-
149
-
In this case, ``bpf_get_file_xattr()`` can be called as::
150
-
151
-
bpf_get_file_xattr(..., "xattr_name", ...);
152
-
153
-
Or::
154
-
155
-
const char name[] = "xattr_name"; /* This need to be global */
156
-
int BPF_PROG(...)
157
-
{
158
-
...
159
-
bpf_get_file_xattr(..., name, ...);
160
-
...
161
-
}
162
-
163
-
2.2.6 __prog Annotation
164
-
---------------------------
165
-
This annotation is used to indicate that the argument needs to be fixed up to
166
-
the bpf_prog_aux of the caller BPF program. Any value passed into this argument
167
-
is ignored, and rewritten by the verifier.
168
-
169
-
An example is given below::
170
-
171
-
__bpf_kfunc int bpf_wq_set_callback_impl(struct bpf_wq *wq,
172
-
int (callback_fn)(void *map, int *key, void *value),
173
-
unsigned int flags,
174
-
void *aux__prog)
175
-
{
176
-
struct bpf_prog_aux *aux = aux__prog;
177
-
...
178
-
}
179
-
180
-
.. _BPF_kfunc_nodef:
181
-
182
-
2.3 Using an existing kernel function
183
-
-------------------------------------
184
-
185
-
When an existing function in the kernel is fit for consumption by BPF programs,
186
-
it can be directly registered with the BPF subsystem. However, care must still
187
-
be taken to review the context in which it will be invoked by the BPF program
188
-
and whether it is safe to do so.
189
-
190
-
2.4 Annotating kfuncs
191
-
---------------------
192
-
193
-
In addition to kfuncs' arguments, verifier may need more information about the
194
-
type of kfunc(s) being registered with the BPF subsystem. To do so, we define
195
-
flags on a set of kfuncs as follows::
196
-
197
-
BTF_KFUNCS_START(bpf_task_set)
198
-
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
199
-
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
200
-
BTF_KFUNCS_END(bpf_task_set)
201
-
202
-
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
203
-
along with it. Ofcourse, it is also allowed to specify no flags.
204
-
205
-
kfunc definitions should also always be annotated with the ``__bpf_kfunc``
206
-
macro. This prevents issues such as the compiler inlining the kfunc if it's a
207
-
static kernel function, or the function being elided in an LTO build as it's
208
-
not used in the rest of the kernel. Developers should not manually add
209
-
annotations to their kfunc to prevent these issues. If an annotation is
210
-
required to prevent such an issue with your kfunc, it is a bug and should be
211
-
added to the definition of the macro so that other kfuncs are similarly
212
-
protected. An example is given below::
213
-
214
-
__bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid)
215
-
{
216
-
...
217
-
}
218
-
219
-
2.4.1 KF_ACQUIRE flag
220
-
---------------------
221
-
222
-
The KF_ACQUIRE flag is used to indicate that the kfunc returns a pointer to a
223
-
refcounted object. The verifier will then ensure that the pointer to the object
224
-
is eventually released using a release kfunc, or transferred to a map using a
225
-
referenced kptr (by invoking bpf_kptr_xchg). If not, the verifier fails the
226
-
loading of the BPF program until no lingering references remain in all possible
227
-
explored states of the program.
228
-
229
-
2.4.2 KF_RET_NULL flag
230
-
----------------------
231
-
232
-
The KF_RET_NULL flag is used to indicate that the pointer returned by the kfunc
233
-
may be NULL. Hence, it forces the user to do a NULL check on the pointer
234
-
returned from the kfunc before making use of it (dereferencing or passing to
235
-
another helper). This flag is often used in pairing with KF_ACQUIRE flag, but
236
-
both are orthogonal to each other.
237
-
238
-
2.4.3 KF_RELEASE flag
239
-
---------------------
240
-
241
-
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
242
-
passed in to it. There can be only one referenced pointer that can be passed
243
-
in. All copies of the pointer being released are invalidated as a result of
244
-
invoking kfunc with this flag. KF_RELEASE kfuncs automatically receive the
245
-
protection afforded by the KF_TRUSTED_ARGS flag described below.
246
-
247
-
2.4.4 KF_TRUSTED_ARGS flag
248
-
--------------------------
249
-
250
-
The KF_TRUSTED_ARGS flag is used for kfuncs taking pointer arguments. It
251
-
indicates that the all pointer arguments are valid, and that all pointers to
252
-
BTF objects have been passed in their unmodified form (that is, at a zero
253
-
offset, and without having been obtained from walking another pointer, with one
254
-
exception described below).
255
-
256
-
There are two types of pointers to kernel objects which are considered "valid":
61
+
There are two types of pointers to kernel objects which are considered "trusted":
257
62
258
63
1. Pointers which are passed as tracepoint or struct_ops callback arguments.
259
64
2. Pointers which were returned from a KF_ACQUIRE kfunc.
260
65
261
66
Pointers to non-BTF objects (e.g. scalar pointers) may also be passed to
262
-
KF_TRUSTED_ARGS kfuncs, and may have a non-zero offset.
67
+
kfuncs, and may have a non-zero offset.
263
68
264
69
The definition of "valid" pointers is subject to change at any time, and has
265
70
absolutely no ABI stability guarantees.
···
113
308
114
309
BTF_TYPE_EMIT(BTF_TYPE_SAFE_TRUSTED(struct socket));
115
310
311
+
2.3 Annotating kfunc parameters
312
+
-------------------------------
116
313
117
-
2.4.5 KF_SLEEPABLE flag
314
+
Similar to BPF helpers, there is sometime need for additional context required
315
+
by the verifier to make the usage of kernel functions safer and more useful.
316
+
Hence, we can annotate a parameter by suffixing the name of the argument of the
317
+
kfunc with a __tag, where tag may be one of the supported annotations.
318
+
319
+
2.3.1 __sz Annotation
320
+
---------------------
321
+
322
+
This annotation is used to indicate a memory and size pair in the argument list.
323
+
An example is given below::
324
+
325
+
__bpf_kfunc void bpf_memzero(void *mem, int mem__sz)
326
+
{
327
+
...
328
+
}
329
+
330
+
Here, the verifier will treat first argument as a PTR_TO_MEM, and second
331
+
argument as its size. By default, without __sz annotation, the size of the type
332
+
of the pointer is used. Without __sz annotation, a kfunc cannot accept a void
333
+
pointer.
334
+
335
+
2.3.2 __k Annotation
336
+
--------------------
337
+
338
+
This annotation is only understood for scalar arguments, where it indicates that
339
+
the verifier must check the scalar argument to be a known constant, which does
340
+
not indicate a size parameter, and the value of the constant is relevant to the
341
+
safety of the program.
342
+
343
+
An example is given below::
344
+
345
+
__bpf_kfunc void *bpf_obj_new(u32 local_type_id__k, ...)
346
+
{
347
+
...
348
+
}
349
+
350
+
Here, bpf_obj_new uses local_type_id argument to find out the size of that type
351
+
ID in program's BTF and return a sized pointer to it. Each type ID will have a
352
+
distinct size, hence it is crucial to treat each such call as distinct when
353
+
values don't match during verifier state pruning checks.
354
+
355
+
Hence, whenever a constant scalar argument is accepted by a kfunc which is not a
356
+
size parameter, and the value of the constant matters for program safety, __k
357
+
suffix should be used.
358
+
359
+
2.3.3 __uninit Annotation
360
+
-------------------------
361
+
362
+
This annotation is used to indicate that the argument will be treated as
363
+
uninitialized.
364
+
365
+
An example is given below::
366
+
367
+
__bpf_kfunc int bpf_dynptr_from_skb(..., struct bpf_dynptr_kern *ptr__uninit)
368
+
{
369
+
...
370
+
}
371
+
372
+
Here, the dynptr will be treated as an uninitialized dynptr. Without this
373
+
annotation, the verifier will reject the program if the dynptr passed in is
374
+
not initialized.
375
+
376
+
2.3.4 __opt Annotation
377
+
-------------------------
378
+
379
+
This annotation is used to indicate that the buffer associated with an __sz or __szk
380
+
argument may be null. If the function is passed a nullptr in place of the buffer,
381
+
the verifier will not check that length is appropriate for the buffer. The kfunc is
382
+
responsible for checking if this buffer is null before using it.
383
+
384
+
An example is given below::
385
+
386
+
__bpf_kfunc void *bpf_dynptr_slice(..., void *buffer__opt, u32 buffer__szk)
387
+
{
388
+
...
389
+
}
390
+
391
+
Here, the buffer may be null. If buffer is not null, it at least of size buffer_szk.
392
+
Either way, the returned buffer is either NULL, or of size buffer_szk. Without this
393
+
annotation, the verifier will reject the program if a null pointer is passed in with
394
+
a nonzero size.
395
+
396
+
2.3.5 __str Annotation
397
+
----------------------------
398
+
This annotation is used to indicate that the argument is a constant string.
399
+
400
+
An example is given below::
401
+
402
+
__bpf_kfunc bpf_get_file_xattr(..., const char *name__str, ...)
403
+
{
404
+
...
405
+
}
406
+
407
+
In this case, ``bpf_get_file_xattr()`` can be called as::
408
+
409
+
bpf_get_file_xattr(..., "xattr_name", ...);
410
+
411
+
Or::
412
+
413
+
const char name[] = "xattr_name"; /* This need to be global */
414
+
int BPF_PROG(...)
415
+
{
416
+
...
417
+
bpf_get_file_xattr(..., name, ...);
418
+
...
419
+
}
420
+
421
+
2.3.6 __prog Annotation
422
+
---------------------------
423
+
This annotation is used to indicate that the argument needs to be fixed up to
424
+
the bpf_prog_aux of the caller BPF program. Any value passed into this argument
425
+
is ignored, and rewritten by the verifier.
426
+
427
+
An example is given below::
428
+
429
+
__bpf_kfunc int bpf_wq_set_callback_impl(struct bpf_wq *wq,
430
+
int (callback_fn)(void *map, int *key, void *value),
431
+
unsigned int flags,
432
+
void *aux__prog)
433
+
{
434
+
struct bpf_prog_aux *aux = aux__prog;
435
+
...
436
+
}
437
+
438
+
.. _BPF_kfunc_nodef:
439
+
440
+
2.4 Using an existing kernel function
441
+
-------------------------------------
442
+
443
+
When an existing function in the kernel is fit for consumption by BPF programs,
444
+
it can be directly registered with the BPF subsystem. However, care must still
445
+
be taken to review the context in which it will be invoked by the BPF program
446
+
and whether it is safe to do so.
447
+
448
+
2.5 Annotating kfuncs
449
+
---------------------
450
+
451
+
In addition to kfuncs' arguments, verifier may need more information about the
452
+
type of kfunc(s) being registered with the BPF subsystem. To do so, we define
453
+
flags on a set of kfuncs as follows::
454
+
455
+
BTF_KFUNCS_START(bpf_task_set)
456
+
BTF_ID_FLAGS(func, bpf_get_task_pid, KF_ACQUIRE | KF_RET_NULL)
457
+
BTF_ID_FLAGS(func, bpf_put_pid, KF_RELEASE)
458
+
BTF_KFUNCS_END(bpf_task_set)
459
+
460
+
This set encodes the BTF ID of each kfunc listed above, and encodes the flags
461
+
along with it. Ofcourse, it is also allowed to specify no flags.
462
+
463
+
kfunc definitions should also always be annotated with the ``__bpf_kfunc``
464
+
macro. This prevents issues such as the compiler inlining the kfunc if it's a
465
+
static kernel function, or the function being elided in an LTO build as it's
466
+
not used in the rest of the kernel. Developers should not manually add
467
+
annotations to their kfunc to prevent these issues. If an annotation is
468
+
required to prevent such an issue with your kfunc, it is a bug and should be
469
+
added to the definition of the macro so that other kfuncs are similarly
470
+
protected. An example is given below::
471
+
472
+
__bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid)
473
+
{
474
+
...
475
+
}
476
+
477
+
2.5.1 KF_ACQUIRE flag
478
+
---------------------
479
+
480
+
The KF_ACQUIRE flag is used to indicate that the kfunc returns a pointer to a
481
+
refcounted object. The verifier will then ensure that the pointer to the object
482
+
is eventually released using a release kfunc, or transferred to a map using a
483
+
referenced kptr (by invoking bpf_kptr_xchg). If not, the verifier fails the
484
+
loading of the BPF program until no lingering references remain in all possible
485
+
explored states of the program.
486
+
487
+
2.5.2 KF_RET_NULL flag
488
+
----------------------
489
+
490
+
The KF_RET_NULL flag is used to indicate that the pointer returned by the kfunc
491
+
may be NULL. Hence, it forces the user to do a NULL check on the pointer
492
+
returned from the kfunc before making use of it (dereferencing or passing to
493
+
another helper). This flag is often used in pairing with KF_ACQUIRE flag, but
494
+
both are orthogonal to each other.
495
+
496
+
2.5.3 KF_RELEASE flag
497
+
---------------------
498
+
499
+
The KF_RELEASE flag is used to indicate that the kfunc releases the pointer
500
+
passed in to it. There can be only one referenced pointer that can be passed
501
+
in. All copies of the pointer being released are invalidated as a result of
502
+
invoking kfunc with this flag.
503
+
504
+
2.5.4 KF_SLEEPABLE flag
118
505
-----------------------
119
506
120
507
The KF_SLEEPABLE flag is used for kfuncs that may sleep. Such kfuncs can only
121
508
be called by sleepable BPF programs (BPF_F_SLEEPABLE).
122
509
123
-
2.4.6 KF_DESTRUCTIVE flag
510
+
2.5.5 KF_DESTRUCTIVE flag
124
511
--------------------------
125
512
126
513
The KF_DESTRUCTIVE flag is used to indicate functions calling which is
···
321
324
calls. At the moment they only require CAP_SYS_BOOT capability, but more can be
322
325
added later.
323
326
324
-
2.4.7 KF_RCU flag
327
+
2.5.6 KF_RCU flag
325
328
-----------------
326
329
327
-
The KF_RCU flag is a weaker version of KF_TRUSTED_ARGS. The kfuncs marked with
328
-
KF_RCU expect either PTR_TRUSTED or MEM_RCU arguments. The verifier guarantees
329
-
that the objects are valid and there is no use-after-free. The pointers are not
330
-
NULL, but the object's refcount could have reached zero. The kfuncs need to
331
-
consider doing refcnt != 0 check, especially when returning a KF_ACQUIRE
332
-
pointer. Note as well that a KF_ACQUIRE kfunc that is KF_RCU should very likely
333
-
also be KF_RET_NULL.
330
+
The KF_RCU flag allows kfuncs to opt out of the default trusted args
331
+
requirement and accept RCU pointers with weaker guarantees. The kfuncs marked
332
+
with KF_RCU expect either PTR_TRUSTED or MEM_RCU arguments. The verifier
333
+
guarantees that the objects are valid and there is no use-after-free. The
334
+
pointers are not NULL, but the object's refcount could have reached zero. The
335
+
kfuncs need to consider doing refcnt != 0 check, especially when returning a
336
+
KF_ACQUIRE pointer. Note as well that a KF_ACQUIRE kfunc that is KF_RCU should
337
+
very likely also be KF_RET_NULL.
334
338
335
-
2.4.8 KF_RCU_PROTECTED flag
339
+
2.5.7 KF_RCU_PROTECTED flag
336
340
---------------------------
337
341
338
342
The KF_RCU_PROTECTED flag is used to indicate that the kfunc must be invoked in
···
352
354
353
355
.. _KF_deprecated_flag:
354
356
355
-
2.4.9 KF_DEPRECATED flag
357
+
2.5.8 KF_DEPRECATED flag
356
358
------------------------
357
359
358
360
The KF_DEPRECATED flag is used for kfuncs which are scheduled to be
···
372
374
in upstream discussions regarding whether to keep, change, deprecate, or remove
373
375
those kfuncs if and when such discussions occur.
374
376
375
-
2.5 Registering the kfuncs
377
+
2.6 Registering the kfuncs
376
378
--------------------------
377
379
378
380
Once the kfunc is prepared for use, the final step to making it visible is
···
395
397
}
396
398
late_initcall(init_subsystem);
397
399
398
-
2.6 Specifying no-cast aliases with ___init
400
+
2.7 Specifying no-cast aliases with ___init
399
401
--------------------------------------------
400
402
401
403
The verifier will always enforce that the BTF type of a pointer passed to a
+3
-7
fs/bpf_fs_kfuncs.c
+3
-7
fs/bpf_fs_kfuncs.c
···
68
68
*
69
69
* Resolve the pathname for the supplied *path* and store it in *buf*. This BPF
70
70
* kfunc is the safer variant of the legacy bpf_d_path() helper and should be
71
-
* used in place of bpf_d_path() whenever possible. It enforces KF_TRUSTED_ARGS
72
-
* semantics, meaning that the supplied *path* must itself hold a valid
73
-
* reference, or else the BPF program will be outright rejected by the BPF
74
-
* verifier.
71
+
* used in place of bpf_d_path() whenever possible.
75
72
*
76
73
* This BPF kfunc may only be called from BPF LSM programs.
77
74
*
···
374
377
return -EACCES;
375
378
}
376
379
377
-
/* bpf_[set|remove]_dentry_xattr.* hooks have KF_TRUSTED_ARGS and
378
-
* KF_SLEEPABLE, so they are only available to sleepable hooks with
379
-
* dentry arguments.
380
+
/* bpf_[set|remove]_dentry_xattr.* hooks have KF_SLEEPABLE, so they are only
381
+
* available to sleepable hooks with dentry arguments.
380
382
*
381
383
* Setting and removing xattr requires exclusive lock on dentry->d_inode.
382
384
* Some hooks already locked d_inode, while some hooks have not locked
+3
-11
kernel/bpf/verifier.c
+3
-11
kernel/bpf/verifier.c
···
12040
12040
return meta->kfunc_flags & KF_RELEASE;
12041
12041
}
12042
12042
12043
-
static bool is_kfunc_trusted_args(struct bpf_kfunc_call_arg_meta *meta)
12044
-
{
12045
-
return (meta->kfunc_flags & KF_TRUSTED_ARGS) || is_kfunc_release(meta);
12046
-
}
12047
-
12048
12043
static bool is_kfunc_sleepable(struct bpf_kfunc_call_arg_meta *meta)
12049
12044
{
12050
12045
return meta->kfunc_flags & KF_SLEEPABLE;
···
13248
13253
return -EINVAL;
13249
13254
}
13250
13255
13251
-
if ((is_kfunc_trusted_args(meta) || is_kfunc_rcu(meta)) &&
13252
-
(register_is_null(reg) || type_may_be_null(reg->type)) &&
13253
-
!is_kfunc_arg_nullable(meta->btf, &args[i])) {
13256
+
if ((register_is_null(reg) || type_may_be_null(reg->type)) &&
13257
+
!is_kfunc_arg_nullable(meta->btf, &args[i]) &&
13258
+
!is_kfunc_arg_optional(meta->btf, &args[i])) {
13254
13259
verbose(env, "Possibly NULL pointer passed to trusted arg%d\n", i);
13255
13260
return -EACCES;
13256
13261
}
···
13315
13320
fallthrough;
13316
13321
case KF_ARG_PTR_TO_ALLOC_BTF_ID:
13317
13322
case KF_ARG_PTR_TO_BTF_ID:
13318
-
if (!is_kfunc_trusted_args(meta) && !is_kfunc_rcu(meta))
13319
-
break;
13320
-
13321
13323
if (!is_trusted_reg(reg)) {
13322
13324
if (!is_kfunc_rcu(meta)) {
13323
13325
verbose(env, "R%d must be referenced or trusted\n", regno);