cramfs: fix bug for wrong filename comparison

PATCH New Holger Brunck 3 participants 5 messages Jul 4, 2013 – Jul 16, 2013 Cramfs filesystem

lore

Share & tools

lore

Holger Brunck

author

2013-07-04 08:29 UTC #0 lore raw

PATCH 1/1 cramfs: fix bug for wrong filename comparison

If we have the following entry in cramfs:
=> cramfsls
-rw-r--r-- 1922689 uImage

cramfsload would also succeed if we try to do:
=> cramfsload uImage_1
CRAMFS load complete: 1922689 bytes loaded to 0x100000

The old code succeeds if the begin of the filename we search matches with a filename stored in cramfs. But the searched file may have additional characters and is therfore not the file we are looking for. So compare also the length of the filename we search and the filename we found in cramfs. This leads to:
=> cramfsload uImage_1
can't find corresponding entry
CRAMFS LOAD ERROR<0> for uImage_1!

which is the behaviour we want.

Signed-off-by Holger Brunck <[email protected]>

cc Wolfgang Denk <[email protected]>

---
 fs/cramfs/cramfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/cramfs/cramfs.c +2 -1

index 910955d..e578a1e 100644
@@ -126,7 +126,8 @@ static unsigned long cramfs_resolve (unsigned long begin, unsigned long offset,
 			namelen--;
 		}
 
-		if (!strncmp (filename, name, namelen)) {
+		if (!strncmp(filename, name, namelen) &&
+		    (namelen == strlen(filename))) {
 			char *p = strtok (NULL, "/");
 
 			if (raw && (p == NULL || *p == '\0'))

Signature · 1 line

1.8.0.1

Albert ARIBAUD

2013-07-05 21:23 UTC #1 lore raw

PATCH 1/1 cramfs: fix bug for wrong filename comparison

Hi Holger,

Quoted 17 lines · Holger Brunck

If we have the following entry in cramfs:
=> cramfsls
-rw-r--r-- 1922689 uImage
cramfsload would also succeed if we try to do:
=> cramfsload uImage_1
CRAMFS load complete: 1922689 bytes loaded to 0x100000
The old code succeeds if the begin of the filename we search matches with a filename stored in cramfs. But the searched file may have additional characters and is therfore not the file we are looking for. So compare also the length of the filename we search and the filename we found in cramfs. This leads to:
=> cramfsload uImage_1
can't find corresponding entry
CRAMFS LOAD ERROR<0> for uImage_1!

Quoted 4 lines

which is the behaviour we want.
Signed-off-by Holger Brunck <[email protected]>
cc Wolfgang Denk <[email protected]>
---

Can't the commit message above be summarized as follows?

---8<---
"cramfsload uImage_1" succeeds even though the actual file is named "uImage".

Fix file name comparison when one name is the prefix of the other. ---8<---

The demonstrative part of the commit message can go here, below the commit message delimiter '---'.

Quoted 8 lines

 fs/cramfs/cramfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/cramfs/cramfs.c +0 -0

index 910955d..e578a1e 100644

fs/cramfs/cramfs.c static unsigned long cramfs_resolve (unsigned long begin, unsigned long offset, · line 133

Quoted 9 lines

fs/cramfs/cramfs.c +2 -1

@@ -126,7 +126,8 @@ static unsigned long cramfs_resolve (unsigned long begin, unsigned long offset,
 			namelen--;
 		}
 
-		if (!strncmp (filename, name, namelen)) {
+		if (!strncmp(filename, name, namelen) &&
+		    (namelen == strlen(filename))) {
 			char *p = strtok (NULL, "/");
 
 			if (raw && (p == NULL || *p == '\0'))

Amicalement,

Signature · 1 line

Albert.

Holger Brunck

author

2013-07-08 06:53 UTC #2 lore raw

PATCH 1/1 cramfs: fix bug for wrong filename comparison

Quoted 31 lines · Albert ARIBAUD

Quoted 17 lines · Holger Brunck
If we have the following entry in cramfs:
=> cramfsls
-rw-r--r-- 1922689 uImage
cramfsload would also succeed if we try to do:
=> cramfsload uImage_1
CRAMFS load complete: 1922689 bytes loaded to 0x100000
The old code succeeds if the begin of the filename we search matches with a filename stored in cramfs. But the searched file may have additional characters and is therfore not the file we are looking for. So compare also the length of the filename we search and the filename we found in cramfs. This leads to:
=> cramfsload uImage_1
can't find corresponding entry
CRAMFS LOAD ERROR<0> for uImage_1!
Quoted 4 lines
which is the behaviour we want.
Signed-off-by Holger Brunck <[email protected]>
cc Wolfgang Denk <[email protected]>
---
Can't the commit message above be summarized as follows?
---8<---
"cramfsload uImage_1" succeeds even though the actual file is named "uImage".

Quoted 6 lines

Fix file name comparison when one name is the prefix of the other. ---8<---
The demonstrative part of the commit message can go here, below the commit message delimiter '---'.

ok. I'll send a v2.

Regards
Holger

Holger Brunck

author

2013-07-08 07:06 UTC #3 lore raw

PATCH v2 1/1 cramfs: fix bug for wrong filename comparison

In reply to Holger Brunck

"cramfsload uImage_1" succeeds even though the actual file is named "uImage".

Fix file name comparison when one name is the prefix of the other.

Signed-off-by Holger Brunck <[email protected]>

cc Wolfgang Denk <[email protected]>

cc Albert ARIBAUD <[email protected]>

---
If we have the following entry in cramfs:
=> cramfsls
-rw-r--r-- 1922689 uImage

cramfsload would also succeed if we try to do:
=> cramfsload uImage_1
CRAMFS load complete: 1922689 bytes loaded to 0x100000

 fs/cramfs/cramfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

fs/cramfs/cramfs.c +2 -1

index 910955d..e578a1e 100644
@@ -126,7 +126,8 @@ static unsigned long cramfs_resolve (unsigned long begin, unsigned long offset,
 			namelen--;
 		}
 
-		if (!strncmp (filename, name, namelen)) {
+		if (!strncmp(filename, name, namelen) &&
+		    (namelen == strlen(filename))) {
 			char *p = strtok (NULL, "/");
 
 			if (raw && (p == NULL || *p == '\0'))

Signature · 1 line

1.8.0.1

Tom Rini

2013-07-16 14:37 UTC #4 lore raw

PATCH v2 1/1 cramfs: fix bug for wrong filename comparison

Quoted 8 lines · Holger Brunck

"cramfsload uImage_1" succeeds even though the actual file is named "uImage".
Fix file name comparison when one name is the prefix of the other.
Signed-off-by Holger Brunck <[email protected]>
cc Wolfgang Denk <[email protected]>
cc Albert ARIBAUD <[email protected]>

Applied to u-boot/master, thanks!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130716/6538f714/attachment.pgp>