Flushing ChunkCache might write incomplete data

[infeo]

When writing to a file channel, for performance reasons cryptofs differs writing on the condition "Does the content to be written fits exaclty in a chunk?"

cryptofs/src/main/java/org/cryptomator/cryptofs/ch/CleartextFileChannel.java

Lines 153 to 159 in ec3871d

	if (offsetInChunk == 0 && len == cleartextChunkSize) {
	// complete chunk, no need to load and decrypt from file
	ByteBuffer cleartextChunkData = bufferPool.getCleartextBuffer();
	src.copyTo(cleartextChunkData);
	cleartextChunkData.flip();
	chunkCache.putChunk(chunkIndex, cleartextChunkData).close();
	} else {

If the condition is true, we directly replace the data in the cache:

cryptofs/src/main/java/org/cryptomator/cryptofs/fh/ChunkCache.java

Lines 82 to 100 in ec3871d

	public Chunk putChunk(long chunkIndex, ByteBuffer chunkData) throws IllegalArgumentException {
	sharedLock.lock();
	try {
	return cachedChunks.compute(chunkIndex, (index, chunk) -> {
	if (chunk == null) {
	chunk = new Chunk(chunkData, true, () -> releaseChunk(chunkIndex));
	} else {
	var dst = chunk.data().duplicate().clear();
	Preconditions.checkArgument(chunkData.remaining() == dst.remaining());
	dst.put(chunkData);
	chunk.dirty().set(true);
	}
	chunk.currentAccesses().incrementAndGet();
	return chunk;
	});
	} finally {
	sharedLock.unlock();
	}
	}

Also here a case distinction is made: Is the Chunk not present? On false, we overwrite the data of the existing chunk by are using JDKs ByteBuffer::duplicate (getting an independet positon and limit.) and placing the data in the duplicate.

But this approach has the problem, that the chunks data limit is not adjusted! Hence, directly flushing the cache afterwards, this chunk contents will only be saved to the outdated limit before the write, leading to invalid ciphertext.

[overheadhunter]

For the record, here is a visualization of what happens in the chunk cache:

// write 1.5 chunks of data:
|xxxx|xx--|

// write 2.5 chunks of data at same pos
|xxxx|xxxx|xx--|

chunks[1] is still cached from the first write, however as it was the EOF chunk, its limit was set to 1/2 of its capacity.

Due to the mentioned „full chunk update“ mechanism, while its bytes were correctly updated during the second write, the limit has not been updated. It still behaves as if it was the last chunk.