[CIR] Make BeginCatchOp target-independent (#190612)
Change the design of BeginCatchOp to be target-independent and handle
the target-specific lowering in the EHLowering pass
if_tuntap: make SIOCIFDESTROY interruptible
There's no good justification to permanently hang a thread until the
tunnel can be destroyed. Make it interruptible so that the admin can
^C it and remedy the situation if something erroneously has the tunnel
open, rather than forcing them to open another shell to resolve it.
Reviewed by: markj
(cherry picked from commit 274bf7c8ae7e7b51853cd541481985f0e687f10e)
ipfw_nptv6: fix handling the ifaddr removal event
The result of IN6_ARE_MASKED_ADDR_EQUAL() macro is not an integer, so
threat it as a boolean value.
PR: 294114
Reported by: Peter Much <pmc citylink dinoex sub org>
(cherry picked from commit d9d7b59486499615a5fdce54443ce62aecf557e8)
workflows/release-asset-audit: Use a GitHub app token (#194085)
This removes one user of the ISSUE_SUBSCRIBER_TOKEN secret, which we
want to eventually remove since secrets are more difficult to maintain.
This also allows use to scope the token with less permissions since it
isn't shared with other workflows.
MC: Group .reloc directive relocations and emit groups in offset order.
The current behavior, where .reloc directives are added to the end of the
symbol's fragment's relocation list, is problematic because a fragment
can be split at an arbitrary point (e.g. due to exceeding FragBlockSize),
and if that point is in the middle of a relocation sequence such as
TLSGD, that can result in an invalid sequence being emitted.
To fix this, modify the behaviour to be closer to what GNU as does, by
maintaining a .reloc group for each fragment while inserting .reloc
relocations. A .reloc group is a consecutive sequence of .reloc
relocations that have an offset <= the first relocation's offset. A
relocation with offset > the first relocation's offset starts a new
group. Relocation groups are inserted in offset order using the offset
of the first relocation, but the source ordering of relocations within
the group is preserved.
Assisted-by: gemini (wrote initial version of llvm/test/MC/X86/reloc-directive-tlsgd.s)
[2 lines not shown]
[AMDGPU] Add gfx13 HSA tests (#194714)
Add HSA tests for gfx13, largely mirroring the gfx12 tests, but covering
the 32 user SGPR limit and related error handling.
libnv: fix heap overflow in nvlist_recv()
nvlist_check_header() validated nvlh_size for overflow before
performing conversion. An mallicous user can set
NV_FLAG_BIG_ENDIAN in the header and craft nvlh_size so that
the orginall value passes the check, but after the conversion the
sizeof(nvlist_header) + size can overflow.
This can lead to a heap buffer overflow.
Approved by: so
Security: FreeBSD-SA-26:17.libnv
Security: CVE-2026-35547
Fixes: 36fa90dbde0060aacb5677d0b113ee168e839071
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56342
libnv: switch fd_wait() from select(2) to poll(2)
The previous implementation used FD_SET() on a stack-allocated fd_set,
which is an out-of-bounds write whenever the socket fd is >= FD_SETSIZE
(1024).
Approved by: so
Security: FreeBSD-SA-26:16.libnv
Security: CVE-2026-39457
Reported by: Joshua Rogers of AISLE Research Team (https://aisle.com/)
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D56689
dhclient: Fix reallocation of dhclient script environments
When the number of DHCP options exceeds a threshold, script_set_env()
will reallocate the environment, stored as an array of pointers. The
calculation of the array size failed to multiply by the pointer size,
resulting in a smaller than expected buffer which admits out-of-bounds
writes.
Approved by: so
Security: FreeBSD-SA-26:15.dhclient
Security: CVE-2026-42511
Reported by: Joshua Rogers of AISLE Research Team (https://aisle.com/)
dhclient: Check for unexpected characters in some DHCP server options
Some options are written directly to the lease file, which may be parsed
by subsequent dhclient invocations. We must make sure that a malicious
server can't control the "medium" field of a lease definition, otherwise
they can achieve RCE by injecting one into the lease file, whereupon it
will be passed to dhclient-script, which passes it through eval.
Approved by: so
Security: FreeBSD-SA-26:12.dhclient
Security: CVE-2026-42511
Reported by: Joshua Rogers of AISLE Research Team (https://aisle.com/)
execve: Fix an operator precedence bug
The buggy version allowed userspace to overflow the copy into adjacent
execve KVA regions, which enables, among other things, injecting
environment variables into privileged processes.
Approved by: so
Security: FreeBSD-SA-26:13.exec
Security: CVE-2026-7270
Reported by: Ryan Austin of Calif.io
Reviewed by: brooks, kib
Fixes: f373437a01a3 ("Add helper functions to copy strings into struct image_args.")
Differential Revision: https://reviews.freebsd.org/D56665
pf: improve SCTP validation
As per RFC5061 "4.2. New Parameter Types" the add/delete IP address
parameters (0xc001, 0xc002) may not be present in an INIT or INIT-ACK
chunk. They are only allowed to be present in an ASCONF chunk.
This also prevents unbounded recursion while parsing an SCTP packet.
Approved by: so
Security: FreeBSD-SA-26:14.pf
Security: CVE-2026-7164
PR: 294799
Reported by: Igor Gabriel Sousa e Souza
Sponsored by: Orange Business Services
amd64: fix INVLPGB range invalidation
AMD64 Architecture Programmer's Manual Volume 3 says the following:
> ECX[15:0] contains a count of the number of sequential pages to
> invalidate in addition to the original virtual address, starting from
> the virtual address specified in rAX. A count of 0 invalidates a
> single page. ECX[31]=0 indicates to increment the virtual address at
> the 4K boundary. ECX[31]=1 indicates to increment the virtual address
> at the 2M boundary. The maximum count supported is reported in
> CPUID function 8000_0008h, EDX[15:0].
ECX[31] being what we call INVLPGB_2M_CNT, signaling to increment the
VA by 2M.
> This instruction invalidates the TLB entry or entries, regardless of
> the page size (4 Kbytes, 2 Mbytes, 4 Mbytes, or 1 Gbyte). [...]
Combined with this, my interpretation of the current code is: if
[24 lines not shown]
pkru: Fix handling of 1GB largepage mappings
pmap_pkru_update_range() did not handle the case where a PDPE has PG_PS
set. More generally, the SET_PKRU and CLEAR_PKRU sysarch
implementations did not check whether the request covers a "boundary" vm
map entry. Fix this, add the missing PG_PS test, and add some tests.
Approved by: so
Security: FreeBSD-SA-26:11.amd64
Security: CVE-2026-6386
Reported by: Nicholas Carlini <npc at anthropic.com>
Reviewed by: kib, alc
Differential Revision: https://reviews.freebsd.org/D56184
tty: Avoid leaving dangling pointers in tty_drop_ctty()
The TIOCNOTTY handler detaches the calling process from its controlling
terminal. It clears the link from the session to the tty, but not the
pointers from the tty to the session and process group. This means that
sess_release() doesn't call tty_rel_sess(), and that pgdelete() doesn't
call tty_rel_pgrp(), so the pointers are left dangling.
Fix this by clearing pointers in tty_drop_ctty(). Add a standalone
regression test.
Approved by: so
Security: FreeBSD-SA-26:10.tty
Security: CVE-2026-5398
Reported by: Nicholas Carlini <npc at anthropic.com>
Reviewed by: kib, kevans
Fixes: 1b50b999f9b5 ("tty: implement TIOCNOTTY")
Differential Revision: https://reviews.freebsd.org/D56046
timerfd: Fix interval callout scheduling
When a timerfd interval callout misses its scheduled activation time, a
differential is calculated based on the actual activation time and the
scheduled activation time. This differential is divided by the timerfd's
interval time and the quotient is added to the timerfd's counter.
Before this change, the next callout was scheduled to activate at:
scheduled activation time + timerfd interval.
This change fixes the scheduling of the next callout to activate at:
actual activation time + timerfd interval - remainder.
Security: FreeBSD-26:06.timerfd
Approved by: so
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D55790
MFC after: 2 weeks
[2 lines not shown]
