summaryrefslogtreecommitdiff
path: root/fs/ubifs
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2010-08-08 12:32:00 +0300
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2010-08-30 10:19:08 +0300
commit5b7a3a2e1b0cbc7d5410a8da60dac266a3e19268 (patch)
treeb663b20a46271d64ba5a94d458d5d87f4c9b24bf /fs/ubifs
parent66576833f5396af34c52160b16d7b8573199282a (diff)
downloadlwn-5b7a3a2e1b0cbc7d5410a8da60dac266a3e19268.tar.gz
lwn-5b7a3a2e1b0cbc7d5410a8da60dac266a3e19268.zip
UBIFS: do not write rubbish into truncation scanning node
In the scanning code, in 'ubifs_add_snod()', we write rubbish into 'snod->key', because we assume that on-flash truncation nodes have a key, but they do not. If the other parts of UBIFS then mistakenly try to look-up the truncation node key (they should not do this, but may do because of a bug), we can succeed and corrupt TNC. It looks like we did have such a situation in 'sort_nodes()' in gc.c. Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Diffstat (limited to 'fs/ubifs')
-rw-r--r--fs/ubifs/scan.c1
1 files changed, 0 insertions, 1 deletions
diff --git a/fs/ubifs/scan.c b/fs/ubifs/scan.c
index 96c525384191..a0a305ca61af 100644
--- a/fs/ubifs/scan.c
+++ b/fs/ubifs/scan.c
@@ -212,7 +212,6 @@ int ubifs_add_snod(const struct ubifs_info *c, struct ubifs_scan_leb *sleb,
case UBIFS_DENT_NODE:
case UBIFS_XENT_NODE:
case UBIFS_DATA_NODE:
- case UBIFS_TRUN_NODE:
/*
* The key is in the same place in all keyed
* nodes.