aboutsummaryrefslogtreecommitdiffstats
path: root/fs/ubifs
diff options
context:
space:
mode:
authorArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2010-08-08 05:32:00 -0400
committerArtem Bityutskiy <Artem.Bityutskiy@nokia.com>2010-08-30 03:19:08 -0400
commit5b7a3a2e1b0cbc7d5410a8da60dac266a3e19268 (patch)
treeb663b20a46271d64ba5a94d458d5d87f4c9b24bf /fs/ubifs
parent66576833f5396af34c52160b16d7b8573199282a (diff)
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,
212 case UBIFS_DENT_NODE: 212 case UBIFS_DENT_NODE:
213 case UBIFS_XENT_NODE: 213 case UBIFS_XENT_NODE:
214 case UBIFS_DATA_NODE: 214 case UBIFS_DATA_NODE:
215 case UBIFS_TRUN_NODE:
216 /* 215 /*
217 * The key is in the same place in all keyed 216 * The key is in the same place in all keyed
218 * nodes. 217 * nodes.