"value":"In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when detecting delalloc ranges during fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nThis however introduced a race that makes us miss delalloc ranges for\nfile regions that are currently holes, so the caller of fiemap will not\nbe aware that there's data for some file regions. This can be quite\nserious for some use cases - for example in coreutils versions before 9.0,\nthe cp program used fiemap to detect holes and data in the source file,\ncopying only regions with data (extents or delalloc) from the source file\nto the destination file in order to preserve holes (see the documentation\nfor its --sparse command line option). This means that if cp was used\nwith a source file that had delalloc in a hole, the destination file could\nend up without that data, which is effectively a data loss issue, if it\nhappened to hit the race described below.\n\nThe race happens like this:\n\n1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that\n has delalloc in the file range [64M, 65M[, which is currently a hole;\n\n2) Fiemap locks the inode in shared mode, then starts iterating the\n inode's subvolume tree searching for file extent items, without having\n the whole fiemap target range locked in the inode's io tree - the\n change introduced recently by commit b0ad381fa769 (\"btrfs: fix\n deadlock with fiemap and extent locking\").Itonlylocksrangesin\ntheiotreewhenitfindsaholeorpreallocextentsincethat\ncommit;\n\n3)Notethatfiemapcloneseachleafbeforeusingit,andthisisto\navoiddeadlockswhenlockingafilerangeintheinode'siotreeand\nthefiemapbufferismemorymappedtosomefile,becausewriting\ntothepagewithbtrfs_page_mkwrite()willwaitonanyorderedextent\nforthepage'srangeandtheorderedextentneedstolocktherange\nandmayneedtomodifythesameleaf,thereforeleadingtoadeadlock\nontheleaf;\n\n4)Whileiteratingthefileextentitemsintheclonedleafbefore\nfindingtheholeintherange[64M,65M[,thedelallocinthatrange\nisflushedanditsorderedextentcompletes-meaningthecorresponding\nfileextentitemisintheinode'ssubvolumetree,butnotpresentin\ntheclonedleafthatfiemapisiteratingover;\n\n5)Whenfiemapfindstheholeinthe[64M,65M[rangebyseeingthegapin\ntheclonedleaf(orafileextentitemwithdisk_bytenr==0incase\ntheNO_HOLESfeatureisnotenabled),itwilllockthatfilerangein\ntheinode'siotreeandthensearchfordelallocbycheckingforthe\nEXTENT_DELALLOCbitintheiotreeforthatrangeandorderedextents\n(withbtrfs_find_delalloc_in_range()).Butitfindsnothingsincethe\ndelallocinthatrangewasalreadyflushedandtheorderedextent\ncompletedandisgone-asaresultfiemapwillnotreportthatthere's\ndelallocoranextentfortherange[64M,65M[,souserspacewillbe\nmisleadintothinkingthatthere'saholeinthatrange.\n\nThiscouldactuallybesporadicallytriggeredwithtestcasegeneric/094\nfromfstests,whichreportsamissingextent/delallocrangelikethis:\n\ngeneric/0942s...-outputmismatch(see/home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)\n --- tests/generic/094.out\t2020-06-10 19:29:03.830519425 +0100\n +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad\t2024-02-28 11:00:00.381071525 +0000\n @@ -1,3 +1,9 @@\n QA output created by 094\n fiemap run with sync\n fiemap run without sync\n +ERROR: couldn't find extent at 7\n +map is 'HHDDHPPDPHPH'\n +logical: [ 5.. 6] phys:\n---trunca