linux-kernel - Oddities in do_read_cache

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f69f7f28-cf24-ebca-41f2-f6cf76435839@suse.de>
Date:   Mon, 27 Jun 2022 11:12:41 +0200
From:   Hannes Reinecke <hare@...e.de>
To:     Matthew Wilcox <matthew@....cx>, Mel Gorman <mgorman@...e.de>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        Jan Kara <jack@...e.cz>
Subject: Oddities in do_read_cache_page()

Hey Matt,

I've stumbled across this code in do_read_cache_page():

         struct folio *folio;

         folio = do_read_cache_folio(mapping, index, filler, file, gfp);
         if (IS_ERR(folio))
                 return &folio->page;
         return folio_file_page(folio, index);

Following 'do_read_cache_folio()' I see that it does things like

                 folio = filemap_alloc_folio(gfp, 0);
                 if (!folio)
                         return ERR_PTR(-ENOMEM);

Now I freely admit that my knowledge of folios is hazy at best, but 
dereferencing an error pointer is something I would seriously frown upon 
  if I were to review the code.
Care to explain?
Or is it, indeed, simply a bug?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@...e.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer