Revert "ciss: Add max physical target"
This reverts commit 45645518ea19ccb4761aee3a525aab2f323d37d4.
Although this changed looks like it should just be a harmless change to
bookkeeping, it turns out that it changes the termination condition of
the initial device scan, resulting in it never finishing. This causes
the boot to hang forever coming up. Since I don't have good access to
hardware, I'm reverting until the exact details can be sorted out.
Reported by: Edward Scroop
Sponsored by: Netflix
MFC After: 1 week
(cherry picked from commit ba9aaed01a484778f1c1f2fb5d7e30dbb1a8f5ad)
www/phpbb3: update to 3.3.17
3.3.14 is affected by CVE-2026-29199 (CVSS 8.1): with force_server_vars
disabled, phpBB builds the password reset link from the HTTP Host
header,
so an attacker who can control that header makes reset mails point to a
domain of their choice, which may lead to account takeover.
Also fixed since 3.3.14: improper state verification in the OAuth
implementation (SECURITY-293), IDOR when composing private messages
(SECURITY-286), CSRF on report submission (SECURITY-287), cross-user
notification read state manipulation (SECURITY-290) and HTML generation
from page data (SECURITY-283).
Changelog:
https://github.com/phpbb/phpbb/blob/release-3.3.17/phpBB/docs/CHANGELOG.html
Security: CVE-2026-29199
Security: 4d06b948-a323-11f1-a655-3497f65b111b
MFH: 2026Q3
[3 lines not shown]
www/phpbb3: update to 3.3.17
3.3.14 is affected by CVE-2026-29199 (CVSS 8.1): with force_server_vars
disabled, phpBB builds the password reset link from the HTTP Host
header,
so an attacker who can control that header makes reset mails point to a
domain of their choice, which may lead to account takeover.
Also fixed since 3.3.14: improper state verification in the OAuth
implementation (SECURITY-293), IDOR when composing private messages
(SECURITY-286), CSRF on report submission (SECURITY-287), cross-user
notification read state manipulation (SECURITY-290) and HTML generation
from page data (SECURITY-283).
Changelog:
https://github.com/phpbb/phpbb/blob/release-3.3.17/phpBB/docs/CHANGELOG.html
Security: CVE-2026-29199
Security: 4d06b948-a323-11f1-a655-3497f65b111b
MFH: 2026Q3
Sponsored by: Netzkommune GmbH
UPDATING: Fix entry for getgroups(2)/setgroups(2)
Fix a typo, grammar, and generally rephrase for better clarity.
Fixes: 3463f02706db ("UPDATING: add an entry for [gs]etgroups")
MFC after: 1 day
MFC to: stable/15
Sponsored by: The FreeBSD Foundation
(cherry picked from commit b7cff2a8c47eb09968430e53cab8b05cf8897d3f)
Add middleware support for LIO ALUA HA
Wire up the middleware side of LIO ALUA high-availability: load
lio_ha.ko with per-node addresses on service start, manage ALUA
state across failover events, clean up STANDBY configfs on pool
export, and add pre-flight validation that targets have static
initiator ACLs before ALUA can be enabled.
For each target, create a portal-less phantom TPG carrying the peer
node's controller group so that a single RTPG response from any
connected port lists both ALUA groups. Write tpgt_N/rtpi explicitly
before enable so that relative target port IDs in RTPG match the
tag formula (portal.tag on Node A, portal.tag + 32000 on Node B)
rather than being auto-assigned sequentially by the kernel.
ALUA group states are driven by role and ha_state:
MASTER + synced local=OPTIMIZED remote=NONOPTIMIZED
MASTER + connected local=OPTIMIZED remote=TRANSITIONING
[4 lines not shown]
[lldb] Fix ProcessProperties reading the wrong experimental collection (#218939)
`ePropertyExperimental` was defined as one past the last generated
process
property, on the assumption that "experimental" is appended next.
lldb/source/Target/Process.cpp:
```
enum {
#define LLDB_PROPERTIES_process
#include "TargetPropertiesEnum.inc" // 0..20
ePropertyExperimental, // 21
};
```
However, the global collection appends "thread" first in
`ProcessProperties::ProcessProperties`,
```
[28 lines not shown]
[CIR] Layout _BitInt types in record/array in CIR as it is in LLVM-IR (#219487)
I've worked through this quite a bit, and spent some time working on
seeing if I could do this during LowerToLLVM, however this causes a ton
of complication, as this level of change affects basically every
member-access invariant that we have. Additionally, we have prior art
(bool -> 8 bits, FP80 -> 128 bits), that I think it makes sense at least
to 'put it with the rest'.
The problem is that the 'i' types for bitint(which they are lowered to)
don't match alignment-wise to the BitInt types. As a result, unless we
do a bunch of transformations to change the struct/array/etc types (plus
the get-member/initialization, etc stuff this entails), we're going
to be reprensenting these types incorrectly. We have prior art for this
as well, particularly around zero-length bitfields (which we represent
as a field in the LLVM-IR to prevent the above conflicts).
This patch does this layout at the CIR level, which gives us layout
parity to LLVM-IR, as well as making sure we represent things correctly
[3 lines not shown]
security/aws-c-auth: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-auth/releases/tag/v1.0.0
devel/aws-c-event-stream: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-event-stream/releases/tag/v1.0.0
devel/aws-c-s3: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-s3/releases/tag/v1.0.0
devel/aws-c-sdkutils: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-sdkutils/releases/tag/v1.0.0
devel/aws-checksums: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-checksums/releases/tag/v1.0.0
devel/aws-c-mqtt: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-mqtt/releases/tag/v1.0.0
devel/aws-c-io: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-io/releases/tag/v1.0.0
security/aws-c-cal: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-cal/releases/tag/v1.0.0
devel/aws-c-http: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
ChangeLog: https://github.com/awslabs/aws-c-http/releases/tag/v1.0.0
devel/aws-c-compression: Update to 1.0.0
CMakeLists.txt looks for AwsGetVersion.cmake from the installed
aws-c-common before project() runs, so LOCALBASE was not searched.
Use USES=localbase, which exports CMAKE_PREFIX_PATH to the environment.
While here, fix typo CNAKE_OFF->CMAKE_OFF
ChangeLog: https://github.com/awslabs/aws-c-compression/releases/tag/v1.0.0
