diff options
| author | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2010-08-08 12:32:00 +0300 |
|---|---|---|
| committer | Artem Bityutskiy <Artem.Bityutskiy@nokia.com> | 2010-08-30 10:19:08 +0300 |
| commit | 5b7a3a2e1b0cbc7d5410a8da60dac266a3e19268 (patch) | |
| tree | b663b20a46271d64ba5a94d458d5d87f4c9b24bf /mm/highmem.c | |
| parent | 66576833f5396af34c52160b16d7b8573199282a (diff) | |
| download | op-kernel-dev-5b7a3a2e1b0cbc7d5410a8da60dac266a3e19268.zip op-kernel-dev-5b7a3a2e1b0cbc7d5410a8da60dac266a3e19268.tar.gz | |
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 'mm/highmem.c')
0 files changed, 0 insertions, 0 deletions
