linux-ext4 - [Bug 201685] ext4 file system corruption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bug-201685-13602-xVRIooH3TV@https.bugzilla.kernel.org/>
Date:   Tue, 04 Dec 2018 21:43:30 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201685] ext4 file system corruption

https://bugzilla.kernel.org/show_bug.cgi?id=201685

--- Comment #245 from Jens Axboe (axboe@...nel.dk) ---
I've only reproduced it that one time, but here's what I think is happening:

- Usually a request is queued, inserted into the blk-mq proper

- There's an optimization in place to attempt to issue to the driver directly
before doing that insert. If we fail because of some resource limitation, we
insert the request into blk-mq proper

- But if that failure did trigger, SCSI has already setup the command. This
means we now have a request in the regular blk-mq IO lists that is mergeable
with other commands, but where the SG tables for IO have already been setup.

- If we later do merge with this IO before dispatch, we'll only do DMA to the
original part of the request. This makes the rest very unhappy...

The case is different because from normal dispatch, if IO needs to be requeued,
it will NEVER be merged/changed after the fact. This means that we don't have
to release SG tables/mappings, we can simply reissue later.

This is just a theory... If I could reproduce more reliably, I'd verify it. I'm
going to spin a quick patch.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.