kernel/fs/pstore, branch linux-5.1.y

pstore: Fix double-free in pstore_mkfile() failure path

2019-07-26T07:13:08Z

commit 4c6d80e1144bdf48cae6b602ae30d41f3e5c76a9 upstream. The pstore_mkfile() function is passed a pointer to a struct pstore_record. On success it consumes this 'record' pointer and references it from the created inode. On failure, however, it may or may not free the record. There are even two different code paths which return -ENOMEM -- one of which does and the other doesn't free the record. Make the behaviour deterministic by never consuming and freeing the record when returning failure, allowing the caller to do the cleanup consistently. Signed-off-by: Norbert Manthey Link: https://lore.kernel.org/r/1562331960-26198-1-git-send-email-nmanthey@amazon.de Fixes: 83f70f0769ddd ("pstore: Do not duplicate record metadata") Fixes: 1dfff7dd67d1a ("pstore: Pass record contents instead of copying") Cc: stable@vger.kernel.org [kees: also move "private" allocation location, rename inode cleanup label] Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore/ram: Run without kernel crash dump region

2019-06-11T10:19:16Z

commit 8880fa32c557600f5f624084152668ed3c2ea51e upstream. The ram pstore backend has always had the crash dumper frontend enabled unconditionally. However, it was possible to effectively disable it by setting a record_size=0. All the machinery would run (storing dumps to the temporary crash buffer), but 0 bytes would ultimately get stored due to there being no przs allocated for dumps. Commit 89d328f637b9 ("pstore/ram: Correctly calculate usable PRZ bytes"), however, assumed that there would always be at least one allocated dprz for calculating the size of the temporary crash buffer. This was, of course, not the case when record_size=0, and would lead to a NULL deref trying to find the dprz buffer size: BUG: unable to handle kernel NULL pointer dereference at (null) ... IP: ramoops_probe+0x285/0x37e (fs/pstore/ram.c:808) cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size; Instead, we need to only enable the frontends based on the success of the prz initialization and only take the needed actions when those zones are available. (This also fixes a possible error in detecting if the ftrace frontend should be enabled.) Reported-and-tested-by: Yaro Slav Fixes: 89d328f637b9 ("pstore/ram: Correctly calculate usable PRZ bytes") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore: Set tfm to NULL on free_buf_for_compression

2019-06-11T10:19:16Z

commit a9fb94a99bb515d8720ba8440ce3aba84aec80f8 upstream. Set tfm to NULL on free_buf_for_compression() after crypto_free_comp(). This avoid a use-after-free when allocate_buf_for_compression() and free_buf_for_compression() are called twice. Although free_buf_for_compression() freed the tfm, allocate_buf_for_compression() won't reinitialize the tfm since the tfm pointer is not NULL. Fixes: 95047b0519c1 ("pstore: Refactor compression initialization") Signed-off-by: Pi-Hsun Shih Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore/ram: Avoid needless alloc during header write

2019-02-12T21:45:53Z

Since the header is a fixed small maximum size, just use a stack variable to avoid memory allocation in the write path. Signed-off-by: Kees Cook

pstore/ram: Add kmsg hlen zero check to ramoops_pstore_write()

2019-02-12T20:38:54Z

If zero-length header happened in ramoops_write_kmsg_hdr(), that means we will not be able to read back dmesg record later, since it will be treated as invalid header in ramoops_pstore_read(). So we should not execute the following code but return the error. Signed-off-by: Yue Hu Signed-off-by: Kees Cook

pstore/ram: Move initialization earlier

2019-02-12T20:10:43Z

Since only one single ramoops area allowed at a time, other probes (like device tree) are meaningless, as it will waste CPU resources. So let's check for being already initialized first. Signed-off-by: Yue Hu Signed-off-by: Kees Cook

pstore: Avoid writing records with zero size

2019-02-12T20:09:49Z

Sometimes pstore_console_write() will write records with zero size to persistent ram zone, which is unnecessary. It will only increase resource consumption. Also adjust ramoops_write_kmsg_hdr() to have same logic if memory allocation fails. Signed-off-by: Yue Hu Signed-off-by: Kees Cook

pstore/ram: Replace dummy_data heap memory with stack memory

2019-01-22T03:32:17Z

In ramoops_register_dummy() dummy_data is allocated via kzalloc() then it will always occupy the heap space after register platform device via platform_device_register_data(), but it will not be used any more. So let's free it for system usage, replace it with stack memory is better due to small size. Signed-off-by: Yue Hu [kees: add required memset and adjust sizeof() argument] Signed-off-by: Kees Cook

pstore/ram: Avoid allocation and leak of platform data

2019-01-20T22:44:52Z

Yue Hu noticed that when parsing device tree the allocated platform data was never freed. Since it's not used beyond the function scope, this switches to using a stack variable instead. Reported-by: Yue Hu Fixes: 35da60941e44 ("pstore/ram: add Device Tree bindings") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook

pstore/ram: Fix console ramoops to show the previous boot logs

2019-01-17T17:14:06Z

commit b05c950698fe ("pstore/ram: Simplify ramoops_get_next_prz() arguments") changed update assignment in getting next persistent ram zone by adding a check for record type. But the check always returns true since the record type is assigned 0. And this breaks console ramoops by showing current console log instead of previous log on warm reset and hard reset (actually hard reset should not be showing any logs). Fix this by having persistent ram zone type check instead of record type check. Tested this on SDM845 MTP and dragonboard 410c. Reproducing this issue is simple as below: 1. Trigger hard reset and mount pstore. Will see console-ramoops record in the mounted location which is the current log. 2. Trigger warm reset and mount pstore. Will see the current console-ramoops record instead of previous record. Fixes: b05c950698fe ("pstore/ram: Simplify ramoops_get_next_prz() arguments") Signed-off-by: Sai Prakash Ranjan Acked-by: Joel Fernandes (Google) [kees: dropped local variable usage] Signed-off-by: Kees Cook