Skip to contentSkip to conversation

staging: pi433: prevent uninitialized data from being printed out

PATCH In review Paulo Miguel Almeida 3 participants 4 messages Feb 26, 2022 – Mar 2, 2022 Staging

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 staging: pi433: prevent uninitialized data from being printed out

local_buffer is not initialised before data is passed to spi_sync_transfer. In case spi* function fails then the dev_dbg statement after that can potentially print out uninitialised data

this patch initialises local_buffer array.

---
Meta-comments:

- this change was requested by Dan Carpenter in a different thread:
https://lore.kernel.org/lkml/20220207100601.GF1951@kadam/

Patch dependency:

- this patch depends on the following patch to be applied first as both of them change the same file:
https://lore.kernel.org/lkml/[email protected]/

---
 drivers/staging/pi433/rf69.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/pi433/rf69.c +1 -1
index e5b23ab39c69..3028018f0b45 100644
@@ -782,7 +782,7 @@ int rf69_read_fifo(struct spi_device *spi, u8 *buffer, unsigned int size)
 {
 	int i;
 	struct spi_transfer transfer;
-	u8 local_buffer[FIFO_SIZE + 1];
+	u8 local_buffer[FIFO_SIZE + 1] = {};
 	int retval;
 
 	if (size > FIFO_SIZE) {
Signature · 1 line
2.34.1
#1 lore raw

Hi Paulo Miguel,

Quoted 7 lines · Paulo Miguel Almeida

local_buffer is not initialised before data is passed to spi_sync_transfer. In case spi* function fails then the dev_dbg statement after that can potentially print out uninitialised data

this patch initialises local_buffer array.

I think, it should have a Fixes: tag.

Quoted 6 lines

---
Meta-comments:

- this change was requested by Dan Carpenter in a different thread:
https://lore.kernel.org/lkml/20220207100601.GF1951@kadam/

Worth mentioning Dan with Reported-by/Suggested-by: :)

Quoted 6 lines

Patch dependency:

- this patch depends on the following patch to be applied first as both of them change the same file:
https://lore.kernel.org/lkml/[email protected]/
---

You can send all these patches as a patch series with proper order. It will help maintainers to not break the order while applying.

Quoted 8 lines
  drivers/staging/pi433/rf69.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
drivers/staging/pi433/rf69.c +0 -0
index e5b23ab39c69..3028018f0b45 100644

drivers/staging/pi433/rf69.c int rf69_read_fifo(struct spi_device *spi, u8 *buffer, unsigned int size) · line 788

Quoted 8 lines
drivers/staging/pi433/rf69.c +1 -1
@@ -782,7 +782,7 @@ int rf69_read_fifo(struct spi_device *spi, u8 *buffer, unsigned int size)
  {
  	int i;
  	struct spi_transfer transfer;
-	u8 local_buffer[FIFO_SIZE + 1];
+	u8 local_buffer[FIFO_SIZE + 1] = {};
  	int retval;
 
  	if (size > FIFO_SIZE) {

With regards,
Pavel Skripkin

#2 lore raw
Quoted 10 lines · Pavel Skripkin
Quoted 6 lines

Patch dependency:

- this patch depends on the following patch to be applied first as both of them change the same file:
https://lore.kernel.org/lkml/[email protected]/
---

You can send all these patches as a patch series with proper order. It will help maintainers to not break the order while applying.

1) All what Pavel said is true.
2) In this case the order does not matter so this text is confusing and unnecessary.
3) Greg is going to see that and he is *never* going to click on that link. In staging then we do not care about the order of patches. Everything is applied in first come first serve basis. If Greg finds out that order matters and it is not sent as a patch set then he just deletes all your patches and asks you to resend everything correctly.

regards,
dan carpenter

#3 lore raw
Quoted 8 lines · Dan Carpenter
Quoted 7 lines · Pavel Skripkin
Quoted 6 lines

Patch dependency:

- this patch depends on the following patch to be applied first as both of them change the same file:
https://lore.kernel.org/lkml/[email protected]/
---

Quoted 5 lines
Quoted 3 lines

You can send all these patches as a patch series with proper order. It will help maintainers to not break the order while applying.

1) All what Pavel said is true.

Hi Pavel, Hi Dan,

thanks for taking the time to review my patch (and apologies for taking this long to reply back to you guys).

This patch ended up being merged yesterday so I will be extra careful for the next patches I send :)

Quoted 6 lines

3) Greg is going to see that and he is *never* going to click on that link. In staging then we do not care about the order of patches. Everything is applied in first come first serve basis. If Greg finds out that order matters and it is not sent as a patch set then he just deletes all your patches and asks you to resend everything correctly.

Noted.

Best regards,

Paulo Almeida