* [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort()
@ 2017-01-17 10:07 linux-kernel-dev
0 siblings, 0 replies; 6+ messages in thread
From: linux-kernel-dev @ 2017-01-17 10:07 UTC (permalink / raw)
To: p.bruenn; +Cc: stable
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
("firmware: Correct handling of fw_state_wait() return value")
fw_load_abort(fw_priv) could be called twice. The first call would
set fw_priv->buf = NULL; and the second call would pass that NULL
to __fw_load_abort() which would dereference that pointer:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.10.0-rc2-CX9020-10+ (patrickbr@lbs1) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #23 PREEMPT Wed Jan 4 08:10:24 CET 2017
[ 0.000000] CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Freescale i.MX53 based Beckhoff CX9020
...
[ 3.098826] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[ 3.115823] pgd = c0004000
[ 3.118632] [00000018] *pgd=00000000
[ 3.122279] Internal error: Oops: 17 [#1] PREEMPT ARM
[ 3.127406] Modules linked in: pwm_imx parallel_display panel_simple uio_pdrv_genirq uio
[ 3.135637] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 4.10.0-rc2-CX9020-10+ #23
[ 3.143313] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 3.149517] Workqueue: events request_firmware_work_func
[ 3.154908] task: dedbde00 task.stack: dee76000
[ 3.159510] PC is at _request_firmware+0x878/0x948
[ 3.164375] LR is at __mutex_lock_slowpath+0x2a8/0x340
[ 3.169576] pc : [<c04ffd80>] lr : [<c073f5e8>] psr: 60030013
sp : dee77e68 ip : dee77e20 fp : dee77ed4
[ 3.181183] r10: dee56a08 r9 : ded92410 r8 : dee56a00
[ 3.186470] r7 : dee77ee4 r6 : fffffffe r5 : def41680 r4 : deeb1e00
[ 3.193070] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 3.199673] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 3.206891] Control: 10c5387d Table: 8e1c8019 DAC: 00000051
[ 3.212704] Process kworker/0:1 (pid: 26, stack limit = 0xdee76210)
[ 3.219044] Stack: (0xdee77e68 to 0xdee78000)
[ 3.223458] 7e60: 7fffffff 00000000 00000001 c0102e2c c0c7a088 c0c735f8
[ 3.231731] 7e80: c0c5124c 00000002 00000001 7fffffff c0c04384 c0d1ae30 00001770 dec9d000
[ 3.240004] 7ea0: dedbde00 c0c12708 00000000 def41580 dee55680 c0c0ff68 df263100 00000000
[ 3.248290] 7ec0: 00000000 c0c6daf8 dee77efc dee77ed8 c04fffbc c04ff514 00000000 00000007
[ 3.256565] 7ee0: 0c0e0832 c01413dc def41580 def41580 dee77f34 dee77f00 c0141420 c04fff8c
[ 3.264841] 7f00: c0c0ff7c dee76038 dee58558 c0c0ff68 dee55698 c0c17e00 c0c0ff7c dee76038
[ 3.273115] 7f20: 00000008 dee55680 dee77f7c dee77f38 c014186c c01412f0 dee77f54 dee76000
[ 3.281387] 7f40: 00000000 dee53cc0 c0c17e00 c0c217a1 dee58558 dee58540 00000000 dee53cc0
[ 3.289667] 7f60: dee55680 c0141810 dee58558 ded0be94 dee77fac dee77f80 c0147dfc c014181c
[ 3.297945] 7f80: dee76000 dee53cc0 c0147ce8 00000000 00000000 00000000 00000000 00000000
[ 3.306217] 7fa0: 00000000 dee77fb0 c0108e18 c0147cf4 00000000 00000000 00000000 00000000
[ 3.314489] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.322762] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[ 3.331055] [<c04ffd80>] (_request_firmware) from [<c04fffbc>] (request_firmware_work_func+0x3c/0x74)
[ 3.343535] [<c04fffbc>] (request_firmware_work_func) from [<c0141420>] (process_one_work+0x13c/0x52c)
[ 3.356057] [<c0141420>] (process_one_work) from [<c014186c>] (worker_thread+0x5c/0x620)
[ 3.367393] [<c014186c>] (worker_thread) from [<c0147dfc>] (kthread+0x114/0x144)
[ 3.378045] [<c0147dfc>] (kthread) from [<c0108e18>] (ret_from_fork+0x14/0x3c)
[ 3.388481] Code: eafffdf5 e59f00bc eb08fe40 e5980100 (e5903018)
[ 3.682255] ---[ end trace dbbc5ea21820dd99 ]---
In above case the call hierarchy looks like:
drivers/dma/imx-sdma.c request_firmware()
-> fw_load_from_user_helper()
-> _request_firmware_load()
-> call fw_state_wait_timeout()
Some time later firmware_loading_store() scans a control value of "-1"
-> switch(loading) case -1: will call
-> fw_load_abort(fw_priv) which calls
-> __fw_load_abort(fw_priv->buf)
-> and set fw_priv->buf = NULL;
back in _request_firmware_load()
fw_state_wait_timeout() returns -ENOENT
-> since mentioned commit
-> fw_load_abort(fw_priv) is called a second time
-> and this time it would call:
-> __fw_load_abort(NULL /* fw_priv->buf */)
-> and we get: NULL->fw_st.status which fits 0x18:
offsetof(struct firmware_buf, fw_st) + offsetof(struct fw_state, status)
Workaround: check buf in fw_load_abort() before passing it to __fw_load_abort().
Fixes: 5d47ec02c37ea632398cb251c884e3a488dff794
("firmware: Correct handling of fw_state_wait() return value")
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
Cc: stable@vger.kernel.org
---
Hi Luis,
It's not my intention to bugging you. I just noticed we got rc4 still
unpatched, so this is my attempt to resend you a version, which might
be easier to apply.
Regards,
Patrick
v2:
- check buf in fw_load_abort() as suggested by Luis/Chris
- add "Fixes:" line
- add stable tag
---
drivers/base/firmware_class.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4497d26..d03e21c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -557,6 +557,9 @@ static void fw_load_abort(struct firmware_priv *fw_priv)
{
struct firmware_buf *buf = fw_priv->buf;
+ if (!buf)
+ return;
+
__fw_load_abort(buf);
/* avoid user action after loading abort */
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort()
@ 2017-01-17 10:08 linux-kernel-dev
2017-01-17 16:20 ` Luis R. Rodriguez
0 siblings, 1 reply; 6+ messages in thread
From: linux-kernel-dev @ 2017-01-17 10:08 UTC (permalink / raw)
To: ming.lei, mcgrof
Cc: gregkh, chris, bjorn.andersson, linux-kernel, Patrick Bruenn,
stable
From: Patrick Bruenn <p.bruenn@beckhoff.com>
Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
("firmware: Correct handling of fw_state_wait() return value")
fw_load_abort(fw_priv) could be called twice. The first call would
set fw_priv->buf = NULL; and the second call would pass that NULL
to __fw_load_abort() which would dereference that pointer:
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.10.0-rc2-CX9020-10+ (patrickbr@lbs1) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #23 PREEMPT Wed Jan 4 08:10:24 CET 2017
[ 0.000000] CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt:Machine model: Freescale i.MX53 based Beckhoff CX9020
...
[ 3.098826] Unable to handle kernel NULL pointer dereference at virtual address 00000018
[ 3.115823] pgd = c0004000
[ 3.118632] [00000018] *pgd=00000000
[ 3.122279] Internal error: Oops: 17 [#1] PREEMPT ARM
[ 3.127406] Modules linked in: pwm_imx parallel_display panel_simple uio_pdrv_genirq uio
[ 3.135637] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 4.10.0-rc2-CX9020-10+ #23
[ 3.143313] Hardware name: Freescale i.MX53 (Device Tree Support)
[ 3.149517] Workqueue: events request_firmware_work_func
[ 3.154908] task: dedbde00 task.stack: dee76000
[ 3.159510] PC is at _request_firmware+0x878/0x948
[ 3.164375] LR is at __mutex_lock_slowpath+0x2a8/0x340
[ 3.169576] pc : [<c04ffd80>] lr : [<c073f5e8>] psr: 60030013
sp : dee77e68 ip : dee77e20 fp : dee77ed4
[ 3.181183] r10: dee56a08 r9 : ded92410 r8 : dee56a00
[ 3.186470] r7 : dee77ee4 r6 : fffffffe r5 : def41680 r4 : deeb1e00
[ 3.193070] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000000
[ 3.199673] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 3.206891] Control: 10c5387d Table: 8e1c8019 DAC: 00000051
[ 3.212704] Process kworker/0:1 (pid: 26, stack limit = 0xdee76210)
[ 3.219044] Stack: (0xdee77e68 to 0xdee78000)
[ 3.223458] 7e60: 7fffffff 00000000 00000001 c0102e2c c0c7a088 c0c735f8
[ 3.231731] 7e80: c0c5124c 00000002 00000001 7fffffff c0c04384 c0d1ae30 00001770 dec9d000
[ 3.240004] 7ea0: dedbde00 c0c12708 00000000 def41580 dee55680 c0c0ff68 df263100 00000000
[ 3.248290] 7ec0: 00000000 c0c6daf8 dee77efc dee77ed8 c04fffbc c04ff514 00000000 00000007
[ 3.256565] 7ee0: 0c0e0832 c01413dc def41580 def41580 dee77f34 dee77f00 c0141420 c04fff8c
[ 3.264841] 7f00: c0c0ff7c dee76038 dee58558 c0c0ff68 dee55698 c0c17e00 c0c0ff7c dee76038
[ 3.273115] 7f20: 00000008 dee55680 dee77f7c dee77f38 c014186c c01412f0 dee77f54 dee76000
[ 3.281387] 7f40: 00000000 dee53cc0 c0c17e00 c0c217a1 dee58558 dee58540 00000000 dee53cc0
[ 3.289667] 7f60: dee55680 c0141810 dee58558 ded0be94 dee77fac dee77f80 c0147dfc c014181c
[ 3.297945] 7f80: dee76000 dee53cc0 c0147ce8 00000000 00000000 00000000 00000000 00000000
[ 3.306217] 7fa0: 00000000 dee77fb0 c0108e18 c0147cf4 00000000 00000000 00000000 00000000
[ 3.314489] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 3.322762] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
[ 3.331055] [<c04ffd80>] (_request_firmware) from [<c04fffbc>] (request_firmware_work_func+0x3c/0x74)
[ 3.343535] [<c04fffbc>] (request_firmware_work_func) from [<c0141420>] (process_one_work+0x13c/0x52c)
[ 3.356057] [<c0141420>] (process_one_work) from [<c014186c>] (worker_thread+0x5c/0x620)
[ 3.367393] [<c014186c>] (worker_thread) from [<c0147dfc>] (kthread+0x114/0x144)
[ 3.378045] [<c0147dfc>] (kthread) from [<c0108e18>] (ret_from_fork+0x14/0x3c)
[ 3.388481] Code: eafffdf5 e59f00bc eb08fe40 e5980100 (e5903018)
[ 3.682255] ---[ end trace dbbc5ea21820dd99 ]---
In above case the call hierarchy looks like:
drivers/dma/imx-sdma.c request_firmware()
-> fw_load_from_user_helper()
-> _request_firmware_load()
-> call fw_state_wait_timeout()
Some time later firmware_loading_store() scans a control value of "-1"
-> switch(loading) case -1: will call
-> fw_load_abort(fw_priv) which calls
-> __fw_load_abort(fw_priv->buf)
-> and set fw_priv->buf = NULL;
back in _request_firmware_load()
fw_state_wait_timeout() returns -ENOENT
-> since mentioned commit
-> fw_load_abort(fw_priv) is called a second time
-> and this time it would call:
-> __fw_load_abort(NULL /* fw_priv->buf */)
-> and we get: NULL->fw_st.status which fits 0x18:
offsetof(struct firmware_buf, fw_st) + offsetof(struct fw_state, status)
Workaround: check buf in fw_load_abort() before passing it to __fw_load_abort().
Fixes: 5d47ec02c37ea632398cb251c884e3a488dff794
("firmware: Correct handling of fw_state_wait() return value")
Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
Cc: stable@vger.kernel.org
---
Hi Luis,
It's not my intention to bugging you. I just noticed we got rc4 still
unpatched, so this is my attempt to resend you a version, which might
be easier to apply.
Regards,
Patrick
v2:
- check buf in fw_load_abort() as suggested by Luis/Chris
- add "Fixes:" line
- add stable tag
---
drivers/base/firmware_class.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4497d26..d03e21c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -557,6 +557,9 @@ static void fw_load_abort(struct firmware_priv *fw_priv)
{
struct firmware_buf *buf = fw_priv->buf;
+ if (!buf)
+ return;
+
__fw_load_abort(buf);
/* avoid user action after loading abort */
--
2.7.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort()
2017-01-17 10:08 [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort() linux-kernel-dev
@ 2017-01-17 16:20 ` Luis R. Rodriguez
0 siblings, 0 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2017-01-17 16:20 UTC (permalink / raw)
To: linux-kernel-dev, Jakub Kicinski
Cc: ming.lei, mcgrof, gregkh, chris, bjorn.andersson, linux-kernel,
Patrick Bruenn, stable
On Tue, Jan 17, 2017 at 11:08:46AM +0100, linux-kernel-dev@beckhoff.com wrote:
> From: Patrick Bruenn <p.bruenn@beckhoff.com>
>
> Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> ("firmware: Correct handling of fw_state_wait() return value")
> fw_load_abort(fw_priv) could be called twice. The first call would
> set fw_priv->buf = NULL; and the second call would pass that NULL
> to __fw_load_abort() which would dereference that pointer:
>
> [ 0.000000] Booting Linux on physical CPU 0x0
> [ 0.000000] Linux version 4.10.0-rc2-CX9020-10+ (patrickbr@lbs1) (gcc version 5.4.0 20160609 (Debian 5.4.0-6) ) #23 PREEMPT Wed Jan 4 08:10:24 CET 2017
> [ 0.000000] CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c5387d
> [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
> [ 0.000000] OF: fdt:Machine model: Freescale i.MX53 based Beckhoff CX9020
> ...
> [ 3.098826] Unable to handle kernel NULL pointer dereference at virtual address 00000018
> [ 3.115823] pgd = c0004000
> [ 3.118632] [00000018] *pgd=00000000
> [ 3.122279] Internal error: Oops: 17 [#1] PREEMPT ARM
> [ 3.127406] Modules linked in: pwm_imx parallel_display panel_simple uio_pdrv_genirq uio
> [ 3.135637] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 4.10.0-rc2-CX9020-10+ #23
> [ 3.143313] Hardware name: Freescale i.MX53 (Device Tree Support)
> [ 3.149517] Workqueue: events request_firmware_work_func
> [ 3.154908] task: dedbde00 task.stack: dee76000
> [ 3.159510] PC is at _request_firmware+0x878/0x948
> [ 3.164375] LR is at __mutex_lock_slowpath+0x2a8/0x340
> [ 3.169576] pc : [<c04ffd80>] lr : [<c073f5e8>] psr: 60030013
> sp : dee77e68 ip : dee77e20 fp : dee77ed4
> [ 3.181183] r10: dee56a08 r9 : ded92410 r8 : dee56a00
> [ 3.186470] r7 : dee77ee4 r6 : fffffffe r5 : def41680 r4 : deeb1e00
> [ 3.193070] r3 : 00000000 r2 : 00000000 r1 : 00000000 r0 : 00000000
> [ 3.199673] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> [ 3.206891] Control: 10c5387d Table: 8e1c8019 DAC: 00000051
> [ 3.212704] Process kworker/0:1 (pid: 26, stack limit = 0xdee76210)
> [ 3.219044] Stack: (0xdee77e68 to 0xdee78000)
> [ 3.223458] 7e60: 7fffffff 00000000 00000001 c0102e2c c0c7a088 c0c735f8
> [ 3.231731] 7e80: c0c5124c 00000002 00000001 7fffffff c0c04384 c0d1ae30 00001770 dec9d000
> [ 3.240004] 7ea0: dedbde00 c0c12708 00000000 def41580 dee55680 c0c0ff68 df263100 00000000
> [ 3.248290] 7ec0: 00000000 c0c6daf8 dee77efc dee77ed8 c04fffbc c04ff514 00000000 00000007
> [ 3.256565] 7ee0: 0c0e0832 c01413dc def41580 def41580 dee77f34 dee77f00 c0141420 c04fff8c
> [ 3.264841] 7f00: c0c0ff7c dee76038 dee58558 c0c0ff68 dee55698 c0c17e00 c0c0ff7c dee76038
> [ 3.273115] 7f20: 00000008 dee55680 dee77f7c dee77f38 c014186c c01412f0 dee77f54 dee76000
> [ 3.281387] 7f40: 00000000 dee53cc0 c0c17e00 c0c217a1 dee58558 dee58540 00000000 dee53cc0
> [ 3.289667] 7f60: dee55680 c0141810 dee58558 ded0be94 dee77fac dee77f80 c0147dfc c014181c
> [ 3.297945] 7f80: dee76000 dee53cc0 c0147ce8 00000000 00000000 00000000 00000000 00000000
> [ 3.306217] 7fa0: 00000000 dee77fb0 c0108e18 c0147cf4 00000000 00000000 00000000 00000000
> [ 3.314489] 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 3.322762] 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
> [ 3.331055] [<c04ffd80>] (_request_firmware) from [<c04fffbc>] (request_firmware_work_func+0x3c/0x74)
> [ 3.343535] [<c04fffbc>] (request_firmware_work_func) from [<c0141420>] (process_one_work+0x13c/0x52c)
> [ 3.356057] [<c0141420>] (process_one_work) from [<c014186c>] (worker_thread+0x5c/0x620)
> [ 3.367393] [<c014186c>] (worker_thread) from [<c0147dfc>] (kthread+0x114/0x144)
> [ 3.378045] [<c0147dfc>] (kthread) from [<c0108e18>] (ret_from_fork+0x14/0x3c)
> [ 3.388481] Code: eafffdf5 e59f00bc eb08fe40 e5980100 (e5903018)
> [ 3.682255] ---[ end trace dbbc5ea21820dd99 ]---
>
> In above case the call hierarchy looks like:
> drivers/dma/imx-sdma.c request_firmware()
> -> fw_load_from_user_helper()
> -> _request_firmware_load()
> -> call fw_state_wait_timeout()
>
> Some time later firmware_loading_store() scans a control value of "-1"
> -> switch(loading) case -1: will call
> -> fw_load_abort(fw_priv) which calls
> -> __fw_load_abort(fw_priv->buf)
> -> and set fw_priv->buf = NULL;
>
> back in _request_firmware_load()
> fw_state_wait_timeout() returns -ENOENT
> -> since mentioned commit
> -> fw_load_abort(fw_priv) is called a second time
> -> and this time it would call:
> -> __fw_load_abort(NULL /* fw_priv->buf */)
> -> and we get: NULL->fw_st.status which fits 0x18:
> offsetof(struct firmware_buf, fw_st) + offsetof(struct fw_state, status)
>
> Workaround: check buf in fw_load_abort() before passing it to __fw_load_abort().
>
> Fixes: 5d47ec02c37ea632398cb251c884e3a488dff794
> ("firmware: Correct handling of fw_state_wait() return value")
>
> Signed-off-by: Patrick Bruenn <p.bruenn@beckhoff.com>
> Cc: stable@vger.kernel.org
> ---
> Hi Luis,
> It's not my intention to bugging you. I just noticed we got rc4 still
> unpatched, so this is my attempt to resend you a version, which might
> be easier to apply.
Thanks but I had suggested for a commit log update (which you did now) but
you changed your patch, I had noted to keep the check in __fw_load_abort().
Can you resend with the change there?
So:
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index b9ac348e8d33..c530f8b4af01 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -542,6 +542,8 @@ static struct firmware_priv *to_firmware_priv(struct device *dev)
static void __fw_load_abort(struct firmware_buf *buf)
{
+ if (!buf)
+ return;
/*
* There is a small window in which user can write to 'loading'
* between loading done and disappearance of 'loading'
> Regards,
> Patrick
>
> v2:
> - check buf in fw_load_abort() as suggested by Luis/Chris
> - add "Fixes:" line
> - add stable tag
> ---
> drivers/base/firmware_class.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
> index 4497d26..d03e21c 100644
> --- a/drivers/base/firmware_class.c
> +++ b/drivers/base/firmware_class.c
> @@ -557,6 +557,9 @@ static void fw_load_abort(struct firmware_priv *fw_priv)
> {
> struct firmware_buf *buf = fw_priv->buf;
>
> + if (!buf)
> + return;
> +
> __fw_load_abort(buf);
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort()
2017-01-25 14:41 [PATCH 7/7] firmware: " Greg KH
@ 2017-01-25 15:21 ` Luis R. Rodriguez
2017-01-25 15:47 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: Luis R. Rodriguez @ 2017-01-25 15:21 UTC (permalink / raw)
To: gregkh
Cc: ming.lei, keescook, linux-kernel-dev, jakub.kicinski, chris,
oss-drivers, johannes, j, teg, kay, jwboyer, dmitry.torokhov,
seth.forshee, bjorn.andersson, linux-kernel, wagi, stephen.boyd,
zohar, tiwai, dwmw2, fengguang.wu, dhowells, arend.vanspriel,
kvalo, kimran, Luis R. Rodriguez, [3.10+]
Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
("firmware: Correct handling of fw_state_wait() return value")
fw_load_abort(fw_priv) could be called twice and lead us to a
kernel crash. This happens only when the firmware fallback mechanism
(regular or custom) is used. The fallback mechanism exposes a sysfs
interface for userspace to upload a file and notify the kernel when
the file is loaded and ready, or to cancel an upload by echo'ing -1
into on the loading file:
echo -n "-1" > /sys/$DEVPATH/loading
This will call fw_load_abort(). Some distributions actually have
a udev rule in place to *always* immediately cancel all firmware
fallback mechanism requests (Debian), they have:
$ cat /lib/udev/rules.d/50-firmware.rules
# stub for immediately telling the kernel that userspace firmware loading
# failed; necessary to avoid long timeouts with CONFIG_FW_LOADER_USER_HELPER=y
SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1
This was done since udev removed the firmware fallback mechanism a while ago
and a long standing misunderstood issues with the timeout (but now corrected).
Distributions with this udev rule would run into this crash only if the
fallback mechanism is used. Since most distributions disable by default
using the fallback mechanism (CONFIG_FW_LOADER_USER_HELPER_FALLBACK), this
would typicaly mean only 2 drivers which *require* the fallback mechanism
could typically incur a crash: drivers/firmware/dell_rbu.c and the
drivers/leds/leds-lp55xx-common.c driver.
The crash happens because after commit 5b029624948d ("firmware: do not
use fw_lock for fw_state protection") and subsequent fix commit
5d47ec02c37ea6 ("firmware: Correct handling of fw_state_wait() return
value") a race can happen between this cancelation and the firmware
fw_state_wait_timeout() being woken up after a state change with which
fw_load_abort() as that calls swake_up(). Upon error fw_state_wait_timeout()
will also again call fw_load_abort() and trigger a null reference.
At first glance we could just fix this with a !buf check on
fw_load_abort() before accessing buf->fw_st, however there is
a logical issue in having a state machine used for the fallback
mechanism and preventing access from it once we abort as its inside
the buf (buf->fw_st).
The firmware_class.c code is setting the buf to NULL to annotate an
abort has occurred. Replace this mechanism by simply using the state check
instead. All the other code in place already uses similar checks
for aborting as well so no further changes are needed.
An oops can be reproduced with the new fw_fallback.sh fallback
mechanism cancellation test. Either cancelling the fallback mechanism
or the custom fallback mechanism triggers a crash.
mcgrof@piggy ~/linux-next/tools/testing/selftests/firmware
(git::20170111-fw-fixes)$ sudo ./fw_fallback.sh
./fw_fallback.sh: timeout works
./fw_fallback.sh: firmware comparison works
./fw_fallback.sh: fallback mechanism works
[ this then sits here when it is trying the cancellation test ]
Kernel log:
test_firmware: loading 'nope-test-firmware.bin'
misc test_firmware: Direct firmware load for nope-test-firmware.bin failed with error -2
misc test_firmware: Falling back to user helper
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
IP: _request_firmware+0xa27/0xad0
PGD 0
Oops: 0000 [#1] SMP
Modules linked in: test_firmware(E) ... etc ...
CPU: 1 PID: 1396 Comm: fw_fallback.sh Tainted: G W E 4.10.0-rc3-next-20170111+ #30
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
task: ffff9740b27f4340 task.stack: ffffbb15c0bc8000
RIP: 0010:_request_firmware+0xa27/0xad0
RSP: 0018:ffffbb15c0bcbd10 EFLAGS: 00010246
RAX: 00000000fffffffe RBX: ffff9740afe5aa80 RCX: 0000000000000000
RDX: ffff9740b27f4340 RSI: 0000000000000283 RDI: 0000000000000000
RBP: ffffbb15c0bcbd90 R08: ffffbb15c0bcbcd8 R09: 0000000000000000
R10: 0000000894a0d4b1 R11: 000000000000008c R12: ffffffffc0312480
R13: 0000000000000005 R14: ffff9740b1c32400 R15: 00000000000003e8
FS: 00007f8604422700(0000) GS:ffff9740bfc80000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000038 CR3: 000000012164c000 CR4: 00000000000006e0
Call Trace:
request_firmware+0x37/0x50
trigger_request_store+0x79/0xd0 [test_firmware]
dev_attr_store+0x18/0x30
sysfs_kf_write+0x37/0x40
kernfs_fop_write+0x110/0x1a0
__vfs_write+0x37/0x160
? _cond_resched+0x1a/0x50
vfs_write+0xb5/0x1a0
SyS_write+0x55/0xc0
? trace_do_page_fault+0x37/0xd0
entry_SYSCALL_64_fastpath+0x1e/0xad
RIP: 0033:0x7f8603f49620
RSP: 002b:00007fff6287b788 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000055c307b110a0 RCX: 00007f8603f49620
RDX: 0000000000000016 RSI: 000055c3084d8a90 RDI: 0000000000000001
RBP: 0000000000000016 R08: 000000000000c0ff R09: 000055c3084d6336
R10: 000055c307b108b0 R11: 0000000000000246 R12: 000055c307b13c80
R13: 000055c3084d6320 R14: 0000000000000000 R15: 00007fff6287b950
Code: 9f 64 84 e8 9c 61 fe ff b8 f4 ff ff ff e9 6b f9 ff
ff 48 c7 c7 40 6b 8d 84 89 45 a8 e8 43 84 18 00 49 8b be 00 03 00 00 8b
45 a8 <83> 7f 38 02 74 08 e8 6e ec ff ff 8b 45 a8 49 c7 86 00 03 00 00
RIP: _request_firmware+0xa27/0xad0 RSP: ffffbb15c0bcbd10
CR2: 0000000000000038
---[ end trace 6d94ac339c133e6f ]---
In above case the call hierarchy that causes the crash looks as follows:
lib/test_firmware.c request_firmware()
-> fw_load_from_user_helper()
-> _request_firmware_load()
-> call fw_state_wait_timeout()
Some time later firmware_loading_store() scans a control value of "-1"
-> switch(loading) case -1: will call
-> fw_load_abort(fw_priv) which calls
-> __fw_load_abort(fw_priv->buf)
-> and set fw_priv->buf = NULL;
Upon being woken up via swake_up(), back in _request_firmware_load()
fw_state_wait_timeout() returns -ENOENT
-> since mentioned commit
-> fw_load_abort(fw_priv) is called a second time
-> and this time it would call:
-> __fw_load_abort(NULL /* fw_priv->buf */)
-> and we get: NULL->fw_st.status
Fixes: 5d47ec02c37e ("firmware: Correct handling of fw_state_wait() return value")
Reported-and-Tested-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reported-and-Tested-by: Patrick Bruenn <p.bruenn@beckhoff.com>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
CC: <stable@vger.kernel.org> [3.10+]
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
v2: adjust commit log to remove the OpenSUSE reference as it doesn't
carry the same udev rule which cancels all fallback requests.
drivers/base/firmware_class.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 4497d263209f..ac350c518e0c 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -558,9 +558,6 @@ static void fw_load_abort(struct firmware_priv *fw_priv)
struct firmware_buf *buf = fw_priv->buf;
__fw_load_abort(buf);
-
- /* avoid user action after loading abort */
- fw_priv->buf = NULL;
}
static LIST_HEAD(pending_fw_head);
@@ -713,7 +710,7 @@ static ssize_t firmware_loading_store(struct device *dev,
mutex_lock(&fw_lock);
fw_buf = fw_priv->buf;
- if (!fw_buf)
+ if (fw_state_is_aborted(&fw_buf->fw_st))
goto out;
switch (loading) {
--
2.11.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort()
2017-01-25 15:21 ` [PATCH v2] " Luis R. Rodriguez
@ 2017-01-25 15:47 ` Greg KH
2017-01-25 18:31 ` Luis R. Rodriguez
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2017-01-25 15:47 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: ming.lei, keescook, linux-kernel-dev, jakub.kicinski, chris,
oss-drivers, johannes, j, teg, kay, jwboyer, dmitry.torokhov,
seth.forshee, bjorn.andersson, linux-kernel, wagi, stephen.boyd,
zohar, tiwai, dwmw2, fengguang.wu, dhowells, arend.vanspriel,
kvalo, kimran, [3.10+]
On Wed, Jan 25, 2017 at 07:21:18AM -0800, Luis R. Rodriguez wrote:
> Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> ("firmware: Correct handling of fw_state_wait() return value")
> fw_load_abort(fw_priv) could be called twice and lead us to a
> kernel crash. This happens only when the firmware fallback mechanism
> (regular or custom) is used. The fallback mechanism exposes a sysfs
> interface for userspace to upload a file and notify the kernel when
> the file is loaded and ready, or to cancel an upload by echo'ing -1
> into on the loading file:
>
> echo -n "-1" > /sys/$DEVPATH/loading
>
> This will call fw_load_abort(). Some distributions actually have
> a udev rule in place to *always* immediately cancel all firmware
> fallback mechanism requests (Debian), they have:
>
> $ cat /lib/udev/rules.d/50-firmware.rules
> # stub for immediately telling the kernel that userspace firmware loading
> # failed; necessary to avoid long timeouts with CONFIG_FW_LOADER_USER_HELPER=y
> SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1
>
> This was done since udev removed the firmware fallback mechanism a while ago
> and a long standing misunderstood issues with the timeout (but now corrected).
> Distributions with this udev rule would run into this crash only if the
> fallback mechanism is used. Since most distributions disable by default
> using the fallback mechanism (CONFIG_FW_LOADER_USER_HELPER_FALLBACK), this
> would typicaly mean only 2 drivers which *require* the fallback mechanism
> could typically incur a crash: drivers/firmware/dell_rbu.c and the
> drivers/leds/leds-lp55xx-common.c driver.
>
> The crash happens because after commit 5b029624948d ("firmware: do not
> use fw_lock for fw_state protection") and subsequent fix commit
> 5d47ec02c37ea6 ("firmware: Correct handling of fw_state_wait() return
> value") a race can happen between this cancelation and the firmware
> fw_state_wait_timeout() being woken up after a state change with which
> fw_load_abort() as that calls swake_up(). Upon error fw_state_wait_timeout()
> will also again call fw_load_abort() and trigger a null reference.
>
> At first glance we could just fix this with a !buf check on
> fw_load_abort() before accessing buf->fw_st, however there is
> a logical issue in having a state machine used for the fallback
> mechanism and preventing access from it once we abort as its inside
> the buf (buf->fw_st).
>
> The firmware_class.c code is setting the buf to NULL to annotate an
> abort has occurred. Replace this mechanism by simply using the state check
> instead. All the other code in place already uses similar checks
> for aborting as well so no further changes are needed.
>
> An oops can be reproduced with the new fw_fallback.sh fallback
> mechanism cancellation test. Either cancelling the fallback mechanism
> or the custom fallback mechanism triggers a crash.
You are still writing books here.
With crazy margins, pick one line width (72 columns), and stick with it
please.
Can you reformat this and resend please?
thanks,
greg k-h-
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort()
2017-01-25 15:47 ` Greg KH
@ 2017-01-25 18:31 ` Luis R. Rodriguez
0 siblings, 0 replies; 6+ messages in thread
From: Luis R. Rodriguez @ 2017-01-25 18:31 UTC (permalink / raw)
To: Greg KH
Cc: Luis R. Rodriguez, ming.lei, keescook, linux-kernel-dev,
jakub.kicinski, chris, oss-drivers, johannes, j, teg, kay,
jwboyer, dmitry.torokhov, seth.forshee, bjorn.andersson,
linux-kernel, wagi, stephen.boyd, zohar, tiwai, dwmw2,
fengguang.wu, dhowells, arend.vanspriel, kvalo, kimran, [3.10+]
On Wed, Jan 25, 2017 at 04:47:25PM +0100, Greg KH wrote:
> On Wed, Jan 25, 2017 at 07:21:18AM -0800, Luis R. Rodriguez wrote:
> > Since commit 5d47ec02c37ea632398cb251c884e3a488dff794
> > ("firmware: Correct handling of fw_state_wait() return value")
> > fw_load_abort(fw_priv) could be called twice and lead us to a
> > kernel crash. This happens only when the firmware fallback mechanism
> > (regular or custom) is used. The fallback mechanism exposes a sysfs
> > interface for userspace to upload a file and notify the kernel when
> > the file is loaded and ready, or to cancel an upload by echo'ing -1
> > into on the loading file:
> >
> > echo -n "-1" > /sys/$DEVPATH/loading
> >
> > This will call fw_load_abort(). Some distributions actually have
> > a udev rule in place to *always* immediately cancel all firmware
> > fallback mechanism requests (Debian), they have:
> >
> > $ cat /lib/udev/rules.d/50-firmware.rules
> > # stub for immediately telling the kernel that userspace firmware loading
> > # failed; necessary to avoid long timeouts with CONFIG_FW_LOADER_USER_HELPER=y
> > SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1
> >
> > This was done since udev removed the firmware fallback mechanism a while ago
> > and a long standing misunderstood issues with the timeout (but now corrected).
> > Distributions with this udev rule would run into this crash only if the
> > fallback mechanism is used. Since most distributions disable by default
> > using the fallback mechanism (CONFIG_FW_LOADER_USER_HELPER_FALLBACK), this
> > would typicaly mean only 2 drivers which *require* the fallback mechanism
> > could typically incur a crash: drivers/firmware/dell_rbu.c and the
> > drivers/leds/leds-lp55xx-common.c driver.
> >
> > The crash happens because after commit 5b029624948d ("firmware: do not
> > use fw_lock for fw_state protection") and subsequent fix commit
> > 5d47ec02c37ea6 ("firmware: Correct handling of fw_state_wait() return
> > value") a race can happen between this cancelation and the firmware
> > fw_state_wait_timeout() being woken up after a state change with which
> > fw_load_abort() as that calls swake_up(). Upon error fw_state_wait_timeout()
> > will also again call fw_load_abort() and trigger a null reference.
> >
> > At first glance we could just fix this with a !buf check on
> > fw_load_abort() before accessing buf->fw_st, however there is
> > a logical issue in having a state machine used for the fallback
> > mechanism and preventing access from it once we abort as its inside
> > the buf (buf->fw_st).
> >
> > The firmware_class.c code is setting the buf to NULL to annotate an
> > abort has occurred. Replace this mechanism by simply using the state check
> > instead. All the other code in place already uses similar checks
> > for aborting as well so no further changes are needed.
> >
> > An oops can be reproduced with the new fw_fallback.sh fallback
> > mechanism cancellation test. Either cancelling the fallback mechanism
> > or the custom fallback mechanism triggers a crash.
>
> You are still writing books here.
Alright trimmed.
> With crazy margins, pick one line width (72 columns), and stick with it
> please.
>
> Can you reformat this and resend please?
Sure.
Luis
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-01-25 18:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-01-17 10:08 [PATCH v2] firmware: fix NULL pointer dereference in __fw_load_abort() linux-kernel-dev
2017-01-17 16:20 ` Luis R. Rodriguez
-- strict thread matches above, loose matches on Subject: below --
2017-01-25 14:41 [PATCH 7/7] firmware: " Greg KH
2017-01-25 15:21 ` [PATCH v2] " Luis R. Rodriguez
2017-01-25 15:47 ` Greg KH
2017-01-25 18:31 ` Luis R. Rodriguez
2017-01-17 10:07 linux-kernel-dev
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).