CVE-2022-48632

What it actually does

Unbounded memcpy loop in mlxbf_i2c_smbus_start_transaction allows stack overwrite when operation length exceeds expected bounds and data_idx increments without validation.

Why it matters to the business

Kernel-level memory corruption on systems using the mlxbf i2c driver can cause crashes, denial of service, or potential code execution affecting Linux-based servers and embedded devices.

How an attack unfolds

An attacker with the ability to trigger or supply crafted SMBus transactions to the mlxbf i2c controller supplies oversized operation lengths that bypass length checks, causing repeated memcpy calls to overflow the stack and corrupt adjacent memory for control-flow hijacking.

How to fix it

Update the Linux kernel to commit 48ee0a864d1af02eea98fc825cc230d61517a71e or later; for fusiondirectory on Debian 11 apply package version 1.3-4+deb11u1 or newer that incorporates the fix.

How to confirm the fix worked

Verify the running kernel contains commit 48ee0a864d1af02eea98fc825cc230d61517a71e via git log or uname; confirm absence of the vulnerable mlxbf_i2c_smbus_start_transaction loop pattern in source or binary.

Typical attack path

1. Identify system exposing mlxbf i2c interface or loadable via userspace i2c tools
2. Craft SMBus transaction with operation length exceeding stack buffer
3. Trigger mlxbf_i2c_smbus_start_transaction in a loop to perform unbounded memcpy
4. Overwrite stack frames or return addresses to redirect execution
5. Escalate to kernel privileges or trigger panic

How to detect it

Review kernel logs for stack trace entries referencing mlxbf_i2c_smbus_start_transaction and memcpy; inspect auditd or syscall logs for unusual i2c ioctl activity from untrusted processes.

What your security team should do

• Prioritize kernel updates on all systems using mlxbf i2c hardware within patch windows
• Audit i2c device exposure and restrict userspace access to i2c-dev nodes
• Monitor EPSS trend and kernel mailing lists for related regressions