[Bug 293888] Fatal trap NUM: general protection fault while in kernel mode in cam_periph_runccb

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 24 Apr 2026 18:38:56 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293888

--- Comment #4 from commit-hook@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=e1cff854997884ed9b7251d409d9c9c7a025606d

commit e1cff854997884ed9b7251d409d9c9c7a025606d
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2026-04-24 18:29:53 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2026-04-24 18:31:55 +0000

    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.

    Replace the XPT_FC_XPT_ONLY blocklist with an explicit allowlist of CCB
    function codes that are known to be safe for userland to submit: I/O
    operations (SCSI, ATA, NVMe, SMP, MMC), device queries, transport
    settings, and a handful of safe control operations (NOOP, REL_SIMQ,
    RESET_DEV, DEBUG). Normally, the /dev/pass* permissions only allow root
    to access them, so this is only a safety issue by default.

    Also reject CAM_DATA_PADDR and CAM_DATA_SG_PADDR, since these pass
    user-supplied physical addresses directly to DMA with no validation,
    which on systems without an IOMMU allows arbitrary host memory access.
    Add `options PASS_UNSAFE_PADDR` to allow the old behavior.

    Verified that camdd, camcontrol, smartmontools, and cdrtools use only
    func_codes on the allowlist (XPT_SCSI_IO, XPT_ATA_IO, XPT_NVME_IO,
    XPT_NVME_ADMIN, XPT_PATH_INQ, XPT_GDEV_TYPE, XPT_GET_TRAN_SETTINGS,
    XPT_SET_TRAN_SETTINGS, XPT_RESET_DEV, XPT_DEBUG) and none use
    CAM_DATA_PADDR.

    PR:                     293888, 293890
    Assisted-By:            Claude Opus 4.6 (1M context)
    Sponsored by:           Netflix
    Reviewed by:            jhb
    Differential Revision:  https://reviews.freebsd.org/D56486

 sys/cam/scsi/scsi_pass.c | 90 ++++++++++++++++++++++++++++++++++++++++++------
 sys/conf/options         |  3 ++
 sys/modules/cam/Makefile |  1 +
 3 files changed, 84 insertions(+), 10 deletions(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.