CVE-2026-46149

What it actually does

A local user who can interact with the Linux kernel SCSI target configuration interface can cause the kernel to read beyond a fixed 256-byte stack buffer while generating target port group membership output. The vulnerable function uses snprintf() to format a LUN path, but then trusts snprintf()'s return value, which can be larger than the actual stack buffer when long iSCSI IQN or fabric WWN names are present. A subsequent memcpy() may copy adjacent stack memory into sysfs/configfs output, causing kernel stack information disclosure. On kernels built with CONFIG_FORTIFY_SOURCE, the same out-of-bounds read can trigger fortify_panic(), resulting in a local denial of service through a kernel panic.

Why it matters to the business

Systems using the Linux kernel SCSI target framework, especially iSCSI target servers, may be vulnerable to local information leakage or crashes if an attacker has sufficient local access to manipulate or read target configuration data. The main operational risk is disruption of storage services due to kernel panic, which can affect workloads depending on exported block storage. The EPSS score is currently very low and there is no known KEV listing or public exploit maturity reported, but the flaw affects kernel code in a privileged storage subsystem and should be prioritized on systems that expose Linux SCSI target functionality.

How an attack unfolds

An attacker first obtains local access to a Linux system where the kernel SCSI target subsystem is enabled and configfs is mounted. The attacker then creates or abuses a SCSI/iSCSI target configuration containing a long fabric WWN or iSCSI IQN value. When the attacker reads the affected target port group members attribute through configfs/sysfs, the kernel formats the LUN path into a 256-byte stack buffer. Because snprintf() reports the length that would have been written rather than the length actually stored, the kernel may use an excessive length in a later memcpy(). That copy reads past the end of the stack buffer. On some builds, adjacent stack bytes are returned to the reader, leaking kernel memory. On hardened builds with CONFIG_FORTIFY_SOURCE, the bounds violation can be detected and converted into a fortify panic, crashing the kernel and interrupting storage and host availability.

How to fix it

Upgrade to a Linux kernel version or distribution kernel package that includes the upstream fix bounding the snprintf() return value before it is used as a memcpy() source length in target_tg_pt_gp_members_show(). No exact fixed package versions were provided, so use vendor advisories for the applicable distribution and kernel stream. Prioritize updates on systems using LIO, iSCSI target, Fibre Channel target, or other SCSI target functionality. If immediate patching is not possible, reduce exposure by disabling unused SCSI target services, unmounting or restricting access to configfs where operationally feasible, limiting administrative access to target configuration, and preventing untrusted local users or containers from interacting with /sys/kernel/config/target. Ensure CONFIG_FORTIFY_SOURCE behavior is understood: it may prevent silent leakage but can turn exploitation into a kernel panic.

How to confirm the fix worked

Confirm the running kernel package contains the vendor backport for this issue by checking the distribution security advisory, kernel changelog, or source patch history for the target_tg_pt_gp_members_show() snprintf length bound fix. Verify whether the system is exposed by checking for enabled SCSI target support and mounted configfs, such as the presence of /sys/kernel/config/target and loaded target_core or iscsi_target_mod modules. After patching, reboot into the fixed kernel and confirm with uname/package inventory that the active kernel is the updated one, not merely installed. In non-production testing only, validate that reading target port group members with long but valid target names no longer leaks unexpected data and does not trigger fortify_panic() or kernel warnings.

Typical attack path

1. Gain local authenticated access to a Linux host running the SCSI target subsystem.
2. Verify that configfs is mounted and that the target core/iSCSI target configuration interface is available.
3. Create or identify a target configuration using an unusually long iSCSI IQN or fabric WWN name.
4. Access the target port group members attribute that invokes the vulnerable tg_pt_gp_members_show() path.
5. Receive leaked stack-adjacent kernel memory in the attribute output, or trigger a fortify panic on hardened kernels.
6. Use the resulting information disclosure to aid further local exploitation, or use the panic condition to cause denial of service.

How to detect it

Evidence of exploitation is most likely to appear in local audit telemetry and kernel logs rather than network logs, because exploitation requires local interaction with configfs/sysfs. Review kernel logs, persistent journal entries, crash dumps, and console logs for fortify_panic(), memcpy bounds failures, target_core_configfs references, or sudden kernel panics occurring near SCSI target configuration activity. Review auditd, eBPF, EDR, or shell history telemetry for reads of target port group members files and creation of unusually long iSCSI IQN or fabric WWN entries under /sys/kernel/config/target. Investigate any local user, automation account, or container process that created or accessed deeply nested target configuration paths with near-maximum-length IQN names. If crash dumping is enabled, inspect vmcore/oops data for call traces involving target_tg_pt_gp_members_show(), target_core_configfs, configfs, or memcpy fortify checks. Because successful information disclosure may leave only a file-read event, absence of logs does not prove absence of exploitation unless detailed file access auditing was already enabled.

• fortify_panic
• target_tg_pt_gp_members_show
• tg_pt_gp_members_show
• target_core_configfs
• detected buffer overflow in memcpy
• Kernel panic - not syncing: fortify_panic
• /sys/kernel/config/target
• /sys/kernel/config/target/iscsi/iqn.
• /sys/kernel/config/target/core
• iscsi_target_mod
• target_core_mod
• CONFIG_FORTIFY_SOURCE

What your security team should do

• Identify Linux systems acting as storage targets or running LIO/iSCSI/SCSI target services and prioritize them for kernel updates.
• Patch or reboot into a vendor-fixed kernel, giving highest priority to multi-user systems and storage infrastructure where local users or delegated administrators can access target configuration.
• Restrict local shell, sudo, container, and automation access that can create or read /sys/kernel/config/target entries until patching is complete.
• Monitor kernel logs for fortify, memcpy, target_core_configfs, and kernel panic messages that may indicate attempted exploitation or accidental triggering.
• Add audit coverage for reads and writes under /sys/kernel/config/target on systems where configfs target administration is security-sensitive.
• Review existing SCSI/iSCSI target names for unusually long IQN or WWN values and investigate unexpected recent changes.
• If storage target functionality is not required, disable the relevant target services/modules and avoid mounting configfs persistently.