Hello Matthew, Thank you for your reply, agree with you its seems wrong fix, will take a look at it.-Atul
On Fri, Aug 25, 2023 at 02:56:28AM +0100, Matthew Wilcox wrote:
On Thu, Aug 24, 2023 at 05:17:21PM -0700, Atul Raut wrote:ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790No. This is your clue. ntfs corrupts memory. You can't take bug reports involving ntfs seriously. Ignore everything tagged with ntfs.In folio_batch_add, which contains folios rather than fixed-size pages, there is a chance that the array index will fall outside of bounds. Before adding folios, examine the available space to fix.This is definitely the wrong fix.static inline unsigned folio_batch_add(struct folio_batch *fbatch, struct folio *folio) { - fbatch->folios[fbatch->nr++] = folio; + if (folio_batch_space(fbatch)) + fbatch->folios[fbatch->nr++] = folio;Did you look at what folio_batch_space() actually does? static inline unsigned int folio_batch_space(struct folio_batch *fbatch) { return PAGEVEC_SIZE - fbatch->nr; } So if fbatch->nr is 255, what will it return? How will folio_batch_add() behave? The right way to fix this problem is to find the data corrupter in NTFS. You can't "fix" it anywhere else.
Attachment:
signature.asc
Description: PGP signature
