* [PATCH] fs: pstore: fix double-free on ramoops_init_przs
@ 2020-01-07 11:04 Cengiz Can
2020-01-07 18:05 ` Kees Cook
0 siblings, 1 reply; 4+ messages in thread
From: Cengiz Can @ 2020-01-07 11:04 UTC (permalink / raw)
To: linux-kernel, Kees Cook, Anton Vorontsov, Colin Cross, Tony Luck
Cc: Cengiz Can
According to Coverity scanner (CID 1457526) kfree on ram.c:591 frees
label which has already been freed.
Here's the flow as I have understood (this is my first time reading
pstore's files):
Whenever `persistent_ram_new` fails, it implicitly calls
`persistent_ram_free(prz)` which already does `kfree(prz->label)` and a
`kfree(prz)` consequently.
Removed `kfree(label)` to prevent double-free.
Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
---
fs/pstore/ram.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 487ee39b4..e196aa08f 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -588,7 +588,6 @@ static int ramoops_init_przs(const char *name,
dev_err(dev, "failed to request %s mem region (0x%zx@0x%llx): %d\n",
name, record_size,
(unsigned long long)*paddr, err);
- kfree(label);
while (i > 0) {
i--;
--
2.24.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] fs: pstore: fix double-free on ramoops_init_przs
2020-01-07 11:04 [PATCH] fs: pstore: fix double-free on ramoops_init_przs Cengiz Can
@ 2020-01-07 18:05 ` Kees Cook
2020-01-07 19:40 ` Cengiz Can
0 siblings, 1 reply; 4+ messages in thread
From: Kees Cook @ 2020-01-07 18:05 UTC (permalink / raw)
To: Cengiz Can; +Cc: linux-kernel, Anton Vorontsov, Colin Cross, Tony Luck
On Tue, Jan 07, 2020 at 02:04:46PM +0300, Cengiz Can wrote:
> According to Coverity scanner (CID 1457526) kfree on ram.c:591 frees
> label which has already been freed.
>
> Here's the flow as I have understood (this is my first time reading
> pstore's files):
>
> Whenever `persistent_ram_new` fails, it implicitly calls
> `persistent_ram_free(prz)` which already does `kfree(prz->label)` and a
> `kfree(prz)` consequently.
>
> Removed `kfree(label)` to prevent double-free.
I think this is a false positive (have you actually hit the
double-free?). The logic in this area is:
label = kmalloc(...)
prz[i] = persistent_ram_new(..., label, ...)
if (IS_ERR(prz[i])) {
kfree(label)
while (i > 0) {
i--;
persistent_ram_free(prz[i]);
}
}
nothing was freeing the label on the failed prz, but all the other prz
labels were free (i.e. there is a "i--" that skips the failed prz
alloc).
-Kees
>
> Signed-off-by: Cengiz Can <cengiz@kernel.wtf>
> ---
> fs/pstore/ram.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 487ee39b4..e196aa08f 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -588,7 +588,6 @@ static int ramoops_init_przs(const char *name,
> dev_err(dev, "failed to request %s mem region (0x%zx@0x%llx): %d\n",
> name, record_size,
> (unsigned long long)*paddr, err);
> - kfree(label);
>
> while (i > 0) {
> i--;
> --
> 2.24.1
>
--
Kees Cook
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs: pstore: fix double-free on ramoops_init_przs
2020-01-07 18:05 ` Kees Cook
@ 2020-01-07 19:40 ` Cengiz Can
2020-01-08 18:01 ` Kees Cook
0 siblings, 1 reply; 4+ messages in thread
From: Cengiz Can @ 2020-01-07 19:40 UTC (permalink / raw)
To: Kees Cook; +Cc: linux-kernel, Anton Vorontsov, Colin Cross, Tony Luck
Hello Kees!
It's a pleasure to hear from you!
On 2020-01-07 21:05, Kees Cook wrote:
>
> I think this is a false positive (have you actually hit the
> double-free?). The logic in this area is:
No I did not actually hit the double-free. I'm just following
the indicators from static analyzer.
> nothing was freeing the label on the failed prz, but all the other prz
> labels were free (i.e. there is a "i--" that skips the failed prz
> alloc).
I have noticed that. Thanks for clearing it up though.
The `kfree` I was referring to is in `err:` label of function
`persistent_ram_new` in `ram_core.c#595` of `for-next/pstore` tree:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/tree/fs/pstore/ram_core.c?h=for-next/pstore#n595
Here are the relevant bits:
```
struct persistent_ram_zone *persistent_ram_new(phys_addr_t start, size_t
size,
u32 sig, struct persistent_ram_ecc_info *ecc_info,
unsigned int memtype, u32 flags, char *label)
{
/* ... */
/* ... */
/* ... */
return prz;
err:
persistent_ram_free(prz); /* <----- */
return ERR_PTR(ret);
}
```
So, to my understanding, if our `persistent_ram_new` call in `ram.c#583`
fails, it already does clean up the `label` pointer in itself and
returns
an ERR_PTR back to us and our skipping logic does its job.
I might be missing something but it seems so.
Thank you for looking into this.
--
Cengiz Can
@cengiz_io
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] fs: pstore: fix double-free on ramoops_init_przs
2020-01-07 19:40 ` Cengiz Can
@ 2020-01-08 18:01 ` Kees Cook
0 siblings, 0 replies; 4+ messages in thread
From: Kees Cook @ 2020-01-08 18:01 UTC (permalink / raw)
To: Cengiz Can; +Cc: linux-kernel, Anton Vorontsov, Colin Cross, Tony Luck
On Tue, Jan 07, 2020 at 10:40:58PM +0300, Cengiz Can wrote:
> Hello Kees!
>
> It's a pleasure to hear from you!
>
> On 2020-01-07 21:05, Kees Cook wrote:
> >
> > I think this is a false positive (have you actually hit the
> > double-free?). The logic in this area is:
>
> No I did not actually hit the double-free. I'm just following
> the indicators from static analyzer.
>
> > nothing was freeing the label on the failed prz, but all the other prz
> > labels were free (i.e. there is a "i--" that skips the failed prz
> > alloc).
>
> I have noticed that. Thanks for clearing it up though.
>
> The `kfree` I was referring to is in `err:` label of function
> `persistent_ram_new` in `ram_core.c#595` of `for-next/pstore` tree:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/tree/fs/pstore/ram_core.c?h=for-next/pstore#n595
>
> Here are the relevant bits:
>
> ```
> struct persistent_ram_zone *persistent_ram_new(phys_addr_t start, size_t
> size,
> u32 sig, struct persistent_ram_ecc_info *ecc_info,
> unsigned int memtype, u32 flags, char *label)
> {
> /* ... */
> /* ... */
> /* ... */
> return prz;
> err:
> persistent_ram_free(prz); /* <----- */
> return ERR_PTR(ret);
> }
> ```
>
> So, to my understanding, if our `persistent_ram_new` call in `ram.c#583`
> fails, it already does clean up the `label` pointer in itself and returns
> an ERR_PTR back to us and our skipping logic does its job.
>
> I might be missing something but it seems so.
>
> Thank you for looking into this.
Ah-ha! Yes, I see it now. We have multiple paths to the err: label, and
I was focused on the kzalloc() failure path. I will get this fixed
better. Thanks!
--
Kees Cook
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-01-08 18:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-07 11:04 [PATCH] fs: pstore: fix double-free on ramoops_init_przs Cengiz Can
2020-01-07 18:05 ` Kees Cook
2020-01-07 19:40 ` Cengiz Can
2020-01-08 18:01 ` Kees Cook
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).