linux-stable.git/drivers/nvmem/core.c, branch v4.4.301

nvmem: Fix shift-out-of-bound (UBSAN) with byte size cells

2021-10-27T07:32:38+00:00

commit 5d388fa01fa6eb310ac023a363a6cb216d9d8fe9 upstream.

If a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic

 *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);

will become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we
subtract one from that making a large number that is then shifted more than the
number of bits that fit into an unsigned long.

UBSAN reports this problem:

 UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8
 shift exponent 64 is too large for 64-bit type 'unsigned long'
 CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9
 Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
 Workqueue: events_unbound deferred_probe_work_func
 Call trace:
  dump_backtrace+0x0/0x170
  show_stack+0x24/0x30
  dump_stack_lvl+0x64/0x7c
  dump_stack+0x18/0x38
  ubsan_epilogue+0x10/0x54
  __ubsan_handle_shift_out_of_bounds+0x180/0x194
  __nvmem_cell_read+0x1ec/0x21c
  nvmem_cell_read+0x58/0x94
  nvmem_cell_read_variable_common+0x4c/0xb0
  nvmem_cell_read_variable_le_u32+0x40/0x100
  a6xx_gpu_init+0x170/0x2f4
  adreno_bind+0x174/0x284
  component_bind_all+0xf0/0x264
  msm_drm_bind+0x1d8/0x7a0
  try_to_bring_up_master+0x164/0x1ac
  __component_add+0xbc/0x13c
  component_add+0x20/0x2c
  dp_display_probe+0x340/0x384
  platform_probe+0xc0/0x100
  really_probe+0x110/0x304
  __driver_probe_device+0xb8/0x120
  driver_probe_device+0x4c/0xfc
  __device_attach_driver+0xb0/0x128
  bus_for_each_drv+0x90/0xdc
  __device_attach+0xc8/0x174
  device_initial_probe+0x20/0x2c
  bus_probe_device+0x40/0xa4
  deferred_probe_work_func+0x7c/0xb8
  process_one_work+0x128/0x21c
  process_scheduled_works+0x40/0x54
  worker_thread+0x1ec/0x2a8
  kthread+0x138/0x158
  ret_from_fork+0x10/0x20

Fix it by making sure there are any bits to mask out.

Fixes: 69aba7948cbe ("nvmem: Add a simple NVMEM framework for consumers")
Cc: Douglas Anderson 
Cc: stable@vger.kernel.org
Signed-off-by: Stephen Boyd 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20211013124511.18726-1-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

nvmem: core: return error code instead of NULL from nvmem_device_get

2019-11-25T14:53:55+00:00

[ Upstream commit ca6ac25cecf0e740d7cc8e03e0ebbf8acbeca3df ]

nvmem_device_get() should return ERR_PTR() on error or valid pointer
on success, but one of the code path seems to return NULL, so fix it.

Reported-by: Niklas Cassel 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

nvmem: core: fix read buffer in place

2019-06-22T06:18:20+00:00

[ Upstream commit 2fe518fecb3a4727393be286db9804cd82ee2d91 ]

When the bit_offset in the cell is zero, the pointer to the msb will
not be properly initialized (ie, will still be pointing to the first
byte in the buffer).

This being the case, if there are bits to clear in the msb, those will
be left untouched while the mask will incorrectly clear bit positions
on the first byte.

This commit also makes sure that any byte unused in the cell is
cleared.

Signed-off-by: Jorge Ramirez-Ortiz 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

nvmem: core: Fix memory leak in nvmem_cell_write

2015-10-04T11:09:43+00:00

A tmp buffer is allocated if cell->bit_offset || cell->nbits.
So the tmp buffer needs to be freed at the same condition to avoid leak.

Signed-off-by: Axel Lin 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman

nvmem: core: Handle shift bits in-place if cell->nbits is non-zero

2015-10-04T11:09:43+00:00

It's pointless to test (cell->bit_offset || cell->bit_offset).
nvmem_shift_read_buffer_in_place() should be called when
(cell->bit_offset || cell->nbits).

Signed-off-by: Axel Lin 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman

nvmem: core: fix the out-of-range leak in read/write()

2015-10-04T11:09:43+00:00

The position to read/write must be less than max
register size.

Signed-off-by: ZhengShunQian 
Acked-by: Srinivas Kandagatla 
Signed-off-by: Srinivas Kandagatla 
Signed-off-by: Greg Kroah-Hartman

nvmem: Add nvmem_device based consumer apis.

2015-08-05T20:43:44+00:00

This patch adds read/write apis which are based on nvmem_device. It is
common that the drivers like omap cape manager or qcom cpr driver to
access bytes directly at particular offset in the eeprom and not from
nvmem cell info in DT. These driver would need to get access to the nvmem
directly, which is what these new APIS provide.

These wrapper apis would help such users to avoid code duplication in
there drivers and also avoid them reading a big eeprom blob and parsing
it internally in there driver.

Signed-off-by: Srinivas Kandagatla 
Tested-by: Stefan Wahren 
Tested-by: Philipp Zabel 
Tested-by: Rajendra Nayak 
Signed-off-by: Greg Kroah-Hartman

nvmem: Add a simple NVMEM framework for consumers

2015-08-05T20:43:12+00:00

This patch adds just consumers part of the framework just to enable easy
review.

Up until now, nvmem drivers were stored in drivers/misc, where they all
had to duplicate pretty much the same code to register a sysfs file,
allow in-kernel users to access the content of the devices they were
driving, etc.

This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data they
require (MAC Addresses, SoC/Revision ID, part numbers, and so on) from
the nvmems.

Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.

Signed-off-by: Maxime Ripard 
[Maxime Ripard: intial version of the framework]
Signed-off-by: Srinivas Kandagatla 
Tested-by: Stefan Wahren 
Tested-by: Philipp Zabel 
Tested-by: Rajendra Nayak 
Signed-off-by: Greg Kroah-Hartman

nvmem: Add a simple NVMEM framework for nvmem providers

2015-08-05T20:43:12+00:00

This patch adds just providers part of the framework just to enable easy
review.

Up until now, NVMEM drivers like eeprom were stored in drivers/misc,
where they all had to duplicate pretty much the same code to register
a sysfs file, allow in-kernel users to access the content of the devices
they were driving, etc.

This was also a problem as far as other in-kernel users were involved,
since the solutions used were pretty much different from on driver to
another, there was a rather big abstraction leak.

This introduction of this framework aims at solving this. It also
introduces DT representation for consumer devices to go get the data
they require (MAC Addresses, SoC/Revision ID, part numbers, and so on)
from the nvmems.

Having regmap interface to this framework would give much better
abstraction for nvmems on different buses.

Signed-off-by: Maxime Ripard 
[Maxime Ripard: intial version of eeprom framework]
Signed-off-by: Srinivas Kandagatla 
Tested-by: Stefan Wahren 
Tested-by: Philipp Zabel 
Tested-by: Rajendra Nayak 
Signed-off-by: Greg Kroah-Hartman