В ядре Linux устранена следующая уязвимость: netfs: Исправить раннюю разблокировку страницы с EOF в середине Коллекция результатов чтения д…

В ядре Linux устранена следующая уязвимость: netfs: Исправить раннюю разблокировку страницы с EOF в середине Коллекция результатов чтения для буферных чтений, кажется, идет впереди выполнение субзапросов при некоторых обстоятельствах, как видно из следующий фрагмент журнала: 9p_client_res: клиент 18446612686390831168 ответ P9_TREAD тег 0 err 0 ... netfs_sreq: R=00001b55[1] ВНИЗ ТЕРММ f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004-0004 read-done netfs_folio: i=157f3 ix=00004-00004-00004 чит-разблокировка netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio: i=157f3 ix=00005-00005 read-done netfs_folio: i=157f3 ix=00005-00005-00005 read-разблокировка ... netfs_colect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_colect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8 ... netfs_sreq: R=00001b55[2] НУЭР СУБМТ f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] НОЛЬ ТЕРМ Ф=102 s=5fb2 4e/4e s=5 e=0 'cto=5fb2' указывает на собранный файл ps мы собрали результаты для до сих пор - но у нас еще есть 0x4e больше байтов, чтобы пойти - так что мы не должны были собранный фолиант ix=00005 еще. Подрек «НУЛ», который очищает хвост происходит после того, как мы разблокируем фолиант, позволяя приложению видеть Неочименный хвост через ммэп. Проблема в том, что netfs_read_unlock_folios() разблокирует фолиант, в котором количество собранных результатов чтения поражает позицию EOF - но ZERO subreq лежит за пределами этого, и так происходит после. Исправьте это, изменив конечную проверку, чтобы всегда быть концом фолио и Никогда не заканчивать файл. В будущем я должен смотреть на расчистку до конца фолио здесь, а не на очистку чем добавить ZERO subreq, чтобы сделать это. С другой стороны, ZERO subreq может работать параллельно с async READ subreq. Кроме того, ZERO subreq может по-прежнему необходимо, скажем, обрабатывать степени в файле цефа, который не имеет backs store и, таким образом, неявно все нули. Это может быть воспроизведено путем создания файла, размер которого не выравнивается к границе страницы, например. 24998 (0x5fb2) байт, а затем что-то делать как: xfs_io -c "mamp -r 0x6000" -c "madvise -d 0x6000" \ -с "мальчик -v 0x6000" /xfstest.test/x Последние 0x4e байты должны быть 00, но если хвост не очищен Тем не менее, вы можете увидеть мусор там. Это может быть воспроизведено с помощью кафов модификация ядра для отключения вызова в netfs_read_subreq_progress() и чтобы остановить afs_issue_read() от проведения ассисенциального звонка для NETFS_READAHEAD. Воспроизведение может быть облегчено путем вставки mdelay(100) в netfs_issue_read() для дела ZERO-subreq. AFS и CIFS обычно вряд ли покажут это, поскольку они отправляют операции READ асинхронно, что позволяет ZERO-subreq финишировать первым. 9P's Читать оп полностью синхронно, поэтому ZERO-subreq всегда будет происходить после. Это не так Однако все время, потому что коллекция может быть сделана в работнике Нить.