CVE-2023-54104

What it actually does

Off-by-one error in fun_exec_op() sanity check allows mchip_number to reach NAND_MAX_CHIPS, causing out-of-bounds read/write on mchip_offsets and rnb_gpio arrays in the fsl_upm NAND driver.

Why it matters to the business

Local kernel memory corruption on systems using Freescale UPM NAND controllers can lead to crashes, denial of service, or potential privilege escalation; the issue affects the stable Linux kernel tree with a fix available since the referenced commit.

How an attack unfolds

An attacker with local access crafts a NAND operation where op-cs equals NAND_MAX_CHIPS; the flawed check copies this value into mchip_number, which is then used as an array index, resulting in out-of-bounds memory access.

How to fix it

Update the Linux kernel to the commit 1f09d67d390647f83f8f9d26382b0daa43756e6f or later; rebuild and deploy the fixed kernel image on all affected systems.

How to confirm the fix worked

Verify the running kernel contains commit 1f09d67d390647f83f8f9d26382b0daa43756e6f; inspect the fun_exec_op() function to confirm the corrected boundary check excludes NAND_MAX_CHIPS.

Typical attack path

1. Gain local code execution on an affected Linux system
2. Identify presence of fsl_upm NAND controller hardware
3. Issue NAND commands with chip-select set to NAND_MAX_CHIPS via userspace interfaces or kernel modules
4. Trigger out-of-bounds access leading to memory corruption or crash

How to detect it

Review kernel logs for oops or panic entries referencing fsl_upm or fun_exec_op; correlate with process activity issuing NAND operations on affected hardware; no public exploitation artifacts are known.

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all systems using fsl_upm NAND hardware
• Test the updated kernel in a staging environment before production rollout
• Monitor for related kernel oops or panic reports indicating possible exploitation attempts