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 "GNU Mach".
The branch, master has been updated
via b46c2dfa327804bd0f8c6ef630608bbf749bf2b5 (commit)
via 874e8419e428b8fd96924beb8d757b27311d410a (commit)
via cb2b448ac1e8574e7fefffc4b153f2fa2bea63c7 (commit)
via 47cc33e11b6867a507fbb23ba127c451b7f3c1ac (commit)
via ec7c3b52480155cc5a090e011ec40a7b7ef49fb5 (commit)
via c5fca45353505c70f4d75482399beb2965e7615f (commit)
via c3ad53fdc77940fc18243d9c9337edba237399dd (commit)
via e77ba1309f4ab284ca0c43f7c8bad46f01f5960c (commit)
from 749d77d9d2ad6f645d27661d44929e308b6607eb (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 b46c2dfa327804bd0f8c6ef630608bbf749bf2b5
Author: Samuel Thibault <[email protected]>
Date: Thu Sep 10 02:50:47 2026 +0200
bpf: Avoid leaking memory content
commit 874e8419e428b8fd96924beb8d757b27311d410a
Author: Denis Ovsienko <[email protected]>
Date: Thu Sep 10 02:50:28 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 cb2b448ac1e8574e7fefffc4b153f2fa2bea63c7
Author: Denis Ovsienko <[email protected]>
Date: Thu Sep 10 02:50:10 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 47cc33e11b6867a507fbb23ba127c451b7f3c1ac
Author: Denis Ovsienko <[email protected]>
Date: Thu Sep 10 02:49:49 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 ec7c3b52480155cc5a090e011ec40a7b7ef49fb5
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 02:49:15 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 c5fca45353505c70f4d75482399beb2965e7615f
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 02:48:49 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 c3ad53fdc77940fc18243d9c9337edba237399dd
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 02:48:23 2026 +0200
Squelch warnings for negating an unsigned value.
commit e77ba1309f4ab284ca0c43f7c8bad46f01f5960c
Author: Guy Harris <[email protected]>
Date: Thu Sep 10 02:47:41 2026 +0200
Support mod and XOR operators.
Same opcodes as on Linux.
-----------------------------------------------------------------------
Summary of changes:
device/net_io.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 59 insertions(+), 7 deletions(-)
hooks/post-receive
--
GNU Mach
