ACK: [SRU][F][PATCH 0/3] CVE-2024-35848

[Thibault Ferrante]

Acked-by: Thibault Ferrante <thibault.ferrante at canonical.com>

On 09-09-2024 03:10, Hui Wang wrote:
> [Impact]
> 
> A nvmem device is registered, after that, there is a one byte reading
> test to the eeprom, if this reading test fails, the device will be
> torn down, but nvmem device is not unregistered, other drivers could
> still access nvmem device, but in this case, it will reference invalid
> memory.
> 
> [Backport]
> 
> To cleanly cherry-pick the patch to focal kernel, at least 10+
> prerequisite patches are needed, If I cherry-pick all of them in the
> focal kernel, it will introduce significant change, especially the pm
> and regulator change, they are unrelevant to this CVE and are risky to
> introduce regression.
> 
> This CVE just needs to move the nvmem registration behind the one byte
> reading test, and before the pm_runtime_idle(). And also need to call
> pm_runtime_disable() if registration fails. Hence I backported 2
> prerequisite commits to introduce pm_runtime_idle() and
> pm_runtime_disable().
> 
> For backporting the major commit f42c97027fb7, I dropped
> pm_runtime_status_suspended(), regulator_disable() and dev_err_probe()
> since there are several prerequisite commits missing in the focal
> kernel:
> cd5676db0574 ("misc: eeprom: at24: support pm_runtime control")
> 2962484dfef8 ("misc: eeprom: at24: check suspend status before disable regulator")
> a3c10035d12f ("eeprom: at24: Use dev_err_probe for nvmem register failure")
> 
> 
> [Fix]
> 
> Noble:  Done
> Jammy:  Done
> Focal:  Backported from mainline v6.9-rc6, see explanation in [Backport]
> Bionic: Not affected
> Xenial: Not affected
> Trusty: Not affected
> 
> [Test Case]
> 
> Building test passed.
> 
> And Tested the patched kernel on a customer's i.MX8 board, the eeprom
> could work as well as before.
> 
> Before applying the patchset:
> root at imx8mp-35som:/sys/bus/nvmem/devices# ls -la
> total 0
> drwxr-xr-x 2 root root 0 Nov 24 03:22 .
> drwxr-xr-x 4 root root 0 Nov 24 03:22 ..
> lrwxrwxrwx 1 root root 0 Nov 24 03:22 1-00520 -> ../../../devices/platform/soc at 0/30800000.bus/30a30000.i2c/i2c-1/1-0052/1-00520
> lrwxrwxrwx 1 root root 0 Nov 24 03:22 imx-ocotp0 -> ../../../devices/platform/soc at 0/30000000.bus/30350000.efuse/imx-ocotp0
> lrwxrwxrwx 1 root root 0 Nov 24 03:22 mtd0 -> ../../../devices/platform/soc at 0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/mtd/mtd0/mtd0
> root at imx8mp-35som:/sys/bus/nvmem/devices# cd 1-00520
> root at imx8mp-35som:/sys/bus/nvmem/devices/1-00520# ls
> nvmem  of_node	power  subsystem  type	uevent
> root at imx8mp-35som:/sys/bus/nvmem/devices/1-00520# hexdump
> nvmem
> 0000000 7830 6666 6666 6666 6666 ff0a ffff ffff
> 0000010 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0000040 6948 742c 6968 2073 7369 6120 206e 6565
> 0000050 7270 6d6f 6574 7473 ff21 ffff ffff ffff
> 0000060 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0001000
> 
> After applying the patchset:
> root at imx8mp-35som:/sys/bus/nvmem/devices# ls -la
> total 0
> drwxr-xr-x 2 root root 0 Nov 24 03:22 .
> drwxr-xr-x 4 root root 0 Nov 24 03:22 ..
> lrwxrwxrwx 1 root root 0 Nov 24 03:22 1-00520 -> ../../../devices/platform/soc at 0/30800000.bus/30a30000.i2c/i2c-1/1-0052/1-00520
> lrwxrwxrwx 1 root root 0 Nov 24 03:22 imx-ocotp0 -> ../../../devices/platform/soc at 0/30000000.bus/30350000.efuse/imx-ocotp0
> lrwxrwxrwx 1 root root 0 Nov 24 03:22 mtd0 -> ../../../devices/platform/soc at 0/30800000.bus/30bb0000.spi/spi_master/spi0/spi0.0/mtd/mtd0/mtd0
> root at imx8mp-35som:/sys/bus/nvmem/devices# cd 1-00520
> root at imx8mp-35som:/sys/bus/nvmem/devices/1-00520# ls
> nvmem  of_node	power  subsystem  type	uevent
> root at imx8mp-35som:/sys/bus/nvmem/devices/1-00520# hexdump nvmem
> 0000000 7830 6666 6666 6666 6666 ff0a ffff ffff
> 0000010 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0000040 6948 742c 6968 2073 7369 6120 206e 6565
> 0000050 7270 6d6f 6574 7473 ff21 ffff ffff ffff
> 0000060 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0001000
> 
> 
> [Where problems could occur]
> 
> The change impacts eeprom driver, if there is regression, it could
> make the eeprom not work anymore.  But the likely of regression is
> very low, the change is straightforward and simple, and I tested the
> patched kernel on an ARM64 platform with eeprom on it,  everything
> worked well.
> 
> 
> Daniel Okazaki (1):
>    eeprom: at24: fix memory corruption race condition
> 
> Michael Auchter (1):
>    misc: eeprom: at24: fix regulator underflow
> 
> Vadym Kochan (1):
>    misc: eeprom: at24: register nvmem only after eeprom is ready to use
> 
>   drivers/misc/eeprom/at24.c | 13 ++++++++-----
>   1 file changed, 8 insertions(+), 5 deletions(-)
> 


-- 
--
Thibault