nda: Filter non-storage nvme drives
Non-stroage drives have namespaces, but no storage attached. These
drives have a different interface type than storage drives, so ignore
them for the nvme_sim, which just handles storage.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D56461
cam: kern.cam.max_high_power tuneable / sysctl
Create a tunable for the maxinum number of 'high power' commands to
schedule, kern.cam.max_high_power. Default remains at 4.
Differential Revision: https://reviews.freebsd.org/D56462
cam: Set ccb_h.status on XPT_GDEVLIST early-return paths
XPT_GDEVLIST in xpt_action_default has two early-return paths (list
changed and index not found) that set cgdl->status but not ccb_h.status.
Since xpt_action sets ccb_h.status to CAM_REQ_INPROG before dispatching,
and XPT_GDEVLIST is an non-queued CCB, cam_periph_ccbwait skips the
sleep loop and immediately hits the KASSERT checking that status !=
CAM_REQ_INPROG, causing a panic.
Set ccb_h.status = CAM_REQ_CMP at the top of the code rather than the
bottom. Any future error paths will be right (since this command can't
fail at the command level, just in the status of the data level).
PR: 293899
Assisted-By: Claude Opus 4.6 (1M context)
Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D56487
pass(4): Allowlist CCB func_codes to harden passthrough ioctls
The pass(4) driver's CAMIOCOMMAND and CAMIOQUEUE ioctls accept arbitrary
CCBs from userland. This device requires root to open, and thus send
these commands. Previously, the only func_code filter was a blocklist
check against the XPT_FC_XPT_ONLY flag. This missed several dangerous
func_codes that lack that flag:
- XPT_ABORT: the abort_ccb field is a raw kernel pointer from the
user CCB payload. xpt_action_default() dereferences it without
validation, leading to kernel crashes or worse.
- XPT_SASYNC_CB: the callback and callback_arg fields come directly
from the user CCB payload and get registered as a kernel async
callback, allowing arbitrary kernel code execution.
- Target mode CCBs (XPT_EN_LUN, XPT_TARGET_IO, etc.) fall through
directly to the SIM with user-controlled payloads.
[23 lines not shown]
acpi_apm: Narrow scope of ACPI_LOCK
This lock doesn't need to be held across seldrain/knlist_destroy. It
is also redundant (and a bug) to hold it across knlist_add and
knlist_remove since it is the mutex for the knlist.
PR: 293901
Reported by: Jiaming Zhang <r772577952 at gmail.com>
Reviewed by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D55994
(cherry picked from commit cc2715cf1f864345ab175db691d4e152d5fb84af)
acpi_apm: Don't recurse on ACPI_LOCK in apmreadfilt
The lock is already held by the caller since it is used as the knlist
lock.
PR: 293901
Reported by: Jiaming Zhang <r772577952 at gmail.com>
Fixes: cc2715cf1f86 ("acpi_apm: Narrow scope of ACPI_LOCK")
(cherry picked from commit 8c941e313e3925b17e49b093244c159db7a112f8)
LinuxKPI: Fix simple_read_from_buffer for zero-size and off-the-end reads
I noticed that the buf_size < 0 check can never be true (it's a
size_t) and decided to check for this condition by an alternate
expression, and I also noticed that a read_size of 0 would incorrectly
return -EFAULT. Instead, return success for both of these cases as
reading beyond the EOF of a normal file also returns EOF, not EINVAL.
Reviewed by: bz
Sponsored by: AFRL, DARPA
Differential Revision: https://reviews.freebsd.org/D55845
(cherry picked from commit 2353fa1aca553883141a7b5d0aa54312a4610412)
