Summary

In mpssas_fw_work's MPI2_EVENT_IR_PHYSICAL_DISK case, the OFFLINE/NOT_CONFIGURED/NOT_COMPATIBLE/default sub-branch of the inner NewValue switch attempts to clear MPS_TARGET_FLAGS_RAID_COMPONENT from targ->flags but writes:

targ->flags |= ~MPS_TARGET_FLAGS_RAID_COMPONENT;

instead of:

targ->flags &= ~MPS_TARGET_FLAGS_RAID_COMPONENT;

The OR-with-complement sets every bit of targ->flags (including RAID_COMPONENT itself), so the disk is never re-exposed to the OS even after it transitions out of the RAID component state.

The opposite branch at line 468 (targ->flags |= MPS_TARGET_FLAGS_RAID_COMPONENT) and the matching mpr_sas_lsi.c sibling both use |= correctly when setting the flag; only the clearing site here is wrong.

Root cause

mps_sas_lsi.c:481:

targ->flags |= ~MPS_TARGET_FLAGS_RAID_COMPONENT;

inside the inner switch (event_data->NewValue) { case MPI2_RAID_PD_STATE_OFFLINE: case MPI2_RAID_PD_STATE_NOT_CONFIGURED: case MPI2_RAID_PD_STATE_NOT_COMPATIBLE: default: ... } of the MPI2_EVENT_IR_PHYSICAL_DISK handler.

The author intended to clear the RAID_COMPONENT bit (exposing the disk to the OS once it leaves the volume) but used bitwise-OR with the complement, which sets bits 0..3, 6..31 (and notably also bit 4 = RAID_COMPONENT, since ~(1<<4) | (1<<4) == 0xFFFFFFFF).

The result: targ->flags is set to all-ones and stays that way. Downstream at mps_sas.c:1579:

if (targ->flags & MPS_TARGET_FLAGS_RAID_COMPONENT)
    return CAM_TID_INVALID;

returns CAM_TID_INVALID for every subsequent SCSI IO to that target — the disk is permanently invisible to the OS after one PhysDisk-state-offline event, until reattachment.

Contrast line 331 (mpssas_rescan_target path) and line 468 (the ONLINE/DEGRADED/REBUILDING/OPTIMAL/HOT_SPARE path) which correctly use |= to set the bit.

Threat model

No direct security impact.

A malicious/compromised SAS HBA that flips a physical disk to OFFLINE/NOT_CONFIGURED/NOT_COMPATIBLE state causes the OS to permanently reject IO to that target (availability-style denial of the disk to userland, but the disk was just declared offline by firmware anyway, so the practical impact is small).

No memory-safety consequence; targ->flags is a plain u32 in a fixed struct slot, so writing 0xFFFFFFFF is in-bounds.

Pure logic bug — defence-in-depth only.

PoC

Not exploitable beyond the logic bug itself. Trigger: a SAS HBA (real or emulated) emits an MPI2_EVENT_IR_PHYSICAL_DISK event with ReasonCode=MPI2_EVENT_IR_PHYSDISK_RC_STATE_CHANGED and NewValue=MPI2_RAID_PD_STATE_OFFLINE (or NOT_CONFIGURED / NOT_COMPATIBLE) for a handle whose target is currently marked as a RAID component.

The target's flags become 0xFFFFFFFF; subsequent SCSI IO via mps_sas_action (mps_sas.c:1579) returns CAM_TID_INVALID indefinitely.

No memory corruption; no privilege gain; no info leak.

Recommended fix

Use the correct operator to clear the bit:

--- a/sys/dev/raid/mps/mps_sas_lsi.c
+++ b/sys/dev/raid/mps/mps_sas_lsi.c
@@ -478,7 +478,7 @@
                    targ = mpssas_find_target_by_handle(sassc, 0,
                            event_data->PhysDiskDevHandle);
                    if (targ) {
-                       targ->flags |= ~MPS_TARGET_FLAGS_RAID_COMPONENT;
+                       targ->flags &= ~MPS_TARGET_FLAGS_RAID_COMPONENT;
                        kprintf("%s %d: Found Target for handle 0x%x.  \n",
                            __func__, __LINE__,
                            event_data->PhysDiskDevHandle);