From: Firo Yang <firogm@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: matt.fleming@intel.com, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, linux-efi@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] x86/efi: fix potential NULL pointer dereference
Date: Sat, 25 Apr 2015 07:15:47 +0000 [thread overview]
Message-ID: <20150425071547.GA12818@firo> (raw)
In-Reply-To: <1429889609.2182.25.camel@HansenPartnership.com>
On Fri, Apr 24, 2015 at 08:33:29AM -0700, James Bottomley wrote:
<On Fri, 2015-04-24 at 14:07 +0800, Firo Yang wrote:
<> In this patch, I add error-handing code for kmalloc() in
<> arch/x86/platform/efi/efi_64.c::efi_call_phys_prolog().
<>
<> If kmalloc() failed to alloc memroy, save_pgd will be a NULL
<> pointer dereferenced by subsequent codes.
<>
<> Signed-off-by: Firo Yang <firogm@gmail.com>
<> ---
<> arch/x86/platform/efi/efi_64.c | 2 ++
<> 1 file changed, 2 insertions(+)
<>
<> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
<> index a0ac0f9..62326c4 100644
<> --- a/arch/x86/platform/efi/efi_64.c
<> +++ b/arch/x86/platform/efi/efi_64.c
<> @@ -90,6 +90,8 @@ pgd_t * __init efi_call_phys_prolog(void)
<>
<> n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
<> save_pgd = kmalloc(n_pgds * sizeof(pgd_t), GFP_KERNEL);
<> + if (unlikely(!save_pgd))
<> + return NULL;
<>
<> for (pgd = 0; pgd < n_pgds; pgd++) {
<> save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
<
<First explain what you're trying to achieve? I'm asking because the
<code you've introduced is actively harmful: the return from
<efi_call_phys_prolog() isn't checked for errors, so the error you return
<won't be handled and we'll likely trigger a much harder to detect error
<if the allocation you're checking fails. Effectively the prolog/epilog
<do nothing and we never restore the pgds we hijacked, yet the system
<continues on with the memory map in an unexpected state.
<
<In my opinion the NULL deref we get further down in the prolog code is
<actually a far better indicator of failure than what you're proposing.
<
<James
<
I feel sorry for introducing this problematic and harmful patch.
I will do more checks and tests before submitting patch next time.
The deep reason is that I did not fully understand these code and
add the error-handing code roughly.
Regards
Firo
WARNING: multiple messages have this Message-ID (diff)
From: Firo Yang <firogm@gmail.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: matt.fleming@intel.com, tglx@linutronix.de, mingo@redhat.com,
hpa@zytor.com, x86@kernel.org, linux-efi@vger.kernel.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] x86/efi: fix potential NULL pointer dereference
Date: Sat, 25 Apr 2015 15:15:47 +0800 [thread overview]
Message-ID: <20150425071547.GA12818@firo> (raw)
In-Reply-To: <1429889609.2182.25.camel@HansenPartnership.com>
On Fri, Apr 24, 2015 at 08:33:29AM -0700, James Bottomley wrote:
<On Fri, 2015-04-24 at 14:07 +0800, Firo Yang wrote:
<> In this patch, I add error-handing code for kmalloc() in
<> arch/x86/platform/efi/efi_64.c::efi_call_phys_prolog().
<>
<> If kmalloc() failed to alloc memroy, save_pgd will be a NULL
<> pointer dereferenced by subsequent codes.
<>
<> Signed-off-by: Firo Yang <firogm@gmail.com>
<> ---
<> arch/x86/platform/efi/efi_64.c | 2 ++
<> 1 file changed, 2 insertions(+)
<>
<> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
<> index a0ac0f9..62326c4 100644
<> --- a/arch/x86/platform/efi/efi_64.c
<> +++ b/arch/x86/platform/efi/efi_64.c
<> @@ -90,6 +90,8 @@ pgd_t * __init efi_call_phys_prolog(void)
<>
<> n_pgds = DIV_ROUND_UP((max_pfn << PAGE_SHIFT), PGDIR_SIZE);
<> save_pgd = kmalloc(n_pgds * sizeof(pgd_t), GFP_KERNEL);
<> + if (unlikely(!save_pgd))
<> + return NULL;
<>
<> for (pgd = 0; pgd < n_pgds; pgd++) {
<> save_pgd[pgd] = *pgd_offset_k(pgd * PGDIR_SIZE);
<
<First explain what you're trying to achieve? I'm asking because the
<code you've introduced is actively harmful: the return from
<efi_call_phys_prolog() isn't checked for errors, so the error you return
<won't be handled and we'll likely trigger a much harder to detect error
<if the allocation you're checking fails. Effectively the prolog/epilog
<do nothing and we never restore the pgds we hijacked, yet the system
<continues on with the memory map in an unexpected state.
<
<In my opinion the NULL deref we get further down in the prolog code is
<actually a far better indicator of failure than what you're proposing.
<
<James
<
I feel sorry for introducing this problematic and harmful patch.
I will do more checks and tests before submitting patch next time.
The deep reason is that I did not fully understand these code and
add the error-handing code roughly.
Regards
Firo
next prev parent reply other threads:[~2015-04-25 7:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 6:07 [PATCH] x86/efi: fix potential NULL pointer dereference Firo Yang
2015-04-24 6:07 ` Firo Yang
[not found] ` <1429855639-14706-1-git-send-email-firogm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-04-24 10:42 ` Dan Carpenter
2015-04-24 10:42 ` Dan Carpenter
2015-04-24 15:33 ` James Bottomley
2015-04-24 15:33 ` James Bottomley
2015-04-25 7:15 ` Firo Yang [this message]
2015-04-25 7:15 ` Firo Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150425071547.GA12818@firo \
--to=firogm@gmail.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=hpa@zytor.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.