This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Hurd".
The branch, master has been updated
via 6067af1282154b55080a6a79171675a930681dfb (commit)
via 3ac15b82dad3a8deb35d9974f5dd85b3fafdb8f7 (commit)
via c8b3034dd707a210cc783d0ae6726bfa43ecdf8e (commit)
via f202612de6f5d61f6edd5beffa4b3d94f96aed21 (commit)
via 76596fecbf5d539850663ad065db290463ab1625 (commit)
via d93abe3184abe8a8afb1df358c9ca5c840933d7b (commit)
via ee74d8486e453fdc9f6b551e5c3a758077b21e9b (commit)
via ac35333957c8c9cf3e1253c707b039ed63ee6fbe (commit)
from 2106848bcf8adcc0a62d46e20af7e37a260f4f91 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 6067af1282154b55080a6a79171675a930681dfb
Author: Samuel Thibault <[email protected]>
Date: Thu Sep 10 02:29:22 2026 +0200
libbpf: Avoid leaking memory content
commit 3ac15b82dad3a8deb35d9974f5dd85b3fafdb8f7
Author: Denis Ovsienko <[email protected]>
Date: Thu Sep 10 01:59:54 2026 +0200
For "lsh" and "rsh" guard "#k" as well.
"lsh x" and "rsh x" in BPF space produce an undefined behaviour in C
space if X > 31 and commit db833b9 prevents exactly that by adding
guards to the BPF interpreter. "lsh #k" and "rsh #k" are a case of the
same problem, except the value is immediate. Although in programs that
have been generated by libpcap these instructions never have k > 31, in
programs that come from an external source via pcap_offline_filter() or
[deprecated] bpf_filter() 'k' can have any value. The validator does
not catch that even if in use, but UBSan eventually does in the
interpreter:
bpf_filter.c:455:6: runtime error: shift exponent 32 is too large for
32-bit type 'unsigned int'
bpf_filter.c:459:6: runtime error: shift exponent 32 is too large for
32-bit type 'unsigned int'
Add the missing guards to the validator and the interpreter to fix the
remaining part of the problem.
commit c8b3034dd707a210cc783d0ae6726bfa43ecdf8e
Author: Denis Ovsienko <[email protected]>
Date: Thu Sep 10 01:56:45 2026 +0200
CVE-2026-6244: Avoid division by zero via pcap_offline_filter().
The current revision of pcapint_filter_with_aux_data() for "div x" and
"mod x" correctly rejects the packet if X is zero, but for "div #k" and
"mod #k" it assumes that k is never zero. This holds for programs that
have been generated or validated by libpcap.
However, this does not necessarily hold for programs that come from an
external source via pcap_offline_filter() or [deprecated] bpf_filter()
and have not been explicitly validated. If the interpreter executes
such a program, it can attempt a division by zero, which will typically
terminate the process via SIGFPE.
To fix this problem, in pcapint_filter_with_aux_data() treat "div #k"
and "mod #k" the same way as "div x" and "mod x".
commit f202612de6f5d61f6edd5beffa4b3d94f96aed21
Author: Denis Ovsienko <[email protected]>
Date: Thu Sep 10 01:47:36 2026 +0200
CVE-2026-0799: Access M[] safely in the BPF interpreter.
Include Security identified and reported this problem as a potential
vulnerability in 2018 (case reference "I7"). Their work was sponsored
by Mozilla under the Secure Open Source program. The vulnerability has
been independently confirmed only recently.
The current revision of pcapint_filter_with_aux_data() can, but does not
check whether a scratch memory register index is valid in the "ld M[k]",
"ldx M[k]", "st M[k]" and "stx M[k]" BPF instructions, and assumes this
is always the case. This holds for programs that have been generated or
validated by libpcap.
However, this does not necessarily hold for programs that come via
pcap_offline_filter() or [deprecated] bpf_filter() from an external
source and have not been explicitly validated. If the interpreter
executes such a program with an invalid index, it will read/write the
process memory at arbitrary locations starting at the current stack
frame. Depending on the address, the memory layout and the OS, this can
result in stack buffer overflow, SIGSEGV, SIGBUS or other effects. To
fix this, in the interpreter reject the packet if the index is invalid.
commit 76596fecbf5d539850663ad065db290463ab1625
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 02:06:51 2026 +0200
Handle negation in a way that doesn't upset compilers or UBSan.
Most BPF arithmetic is unsigned, but negation can't be unsigned;
respecify it as subtracting the value from 0U, so that 1) we don't get
compiler warnings about negating an unsigned value and 2) don't get
UBSan warnings about the result of negating 0x80000000 being undefined.
Credit to OSS-Fuzz for finding these issues.
commit d93abe3184abe8a8afb1df358c9ca5c840933d7b
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 02:02:26 2026 +0200
Fix the semantics of BPF_LSH and BPF_RSH for shifts >= 32 bits.
Some processors treat shifts greater than the width of the shifted
operand as setting the destination to 0, some others treat it as a shift
modulo the width.
C says it's undefined, and most if not all implementations make it work
the way the target processor works.
We treat it as setting the destination to 0, regardless of how the
processor on which we're running works.
Credit to OSS-Fuzz for finding this issue.
commit ee74d8486e453fdc9f6b551e5c3a758077b21e9b
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 02:04:45 2026 +0200
Squelch warnings for negating an unsigned value.
commit ac35333957c8c9cf3e1253c707b039ed63ee6fbe
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 01:53:12 2026 +0200
Support mod and XOR operators.
Same opcodes as on Linux.
-----------------------------------------------------------------------
Summary of changes:
libbpf/bpf_impl.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 58 insertions(+), 7 deletions(-)
hooks/post-receive
--
Hurd
