2019-09-18 17:39:17

by Allen

Subject: [PATCH] drivers/net/fjes: fix a potential NULL pointer dereference

alloc_workqueue is not checked for errors and as a result,
a potential NULL dereference could occur.

Signed-off-by: Allen Pais <[email protected]>
---
drivers/net/fjes/fjes_main.c | 7 +++++++
1 file changed, 7 insertions(+)

diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
index bbbc1dc..2d04104 100644
--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1237,8 +1237,15 @@ static int fjes_probe(struct platform_device *plat_dev)
adapter->open_guard = false;

adapter->txrx_wq = alloc_workqueue(DRV_NAME "/txrx", WQ_MEM_RECLAIM, 0);
+ if (unlikely(!adapter->txrx_wq))
+ goto err_free_netdev;
+
adapter->control_wq = alloc_workqueue(DRV_NAME "/control",
WQ_MEM_RECLAIM, 0);
+ if (unlikely(!adapter->control_wq)) {
+ destroy_workqueue(adapter->txrx_wq);
+ goto err_free_netdev;
+ }

INIT_WORK(&adapter->tx_stall_task, fjes_tx_stall_task);
INIT_WORK(&adapter->raise_intr_rxdata_task,
--
1.9.1

2019-09-23 18:29:14

by Jakub Kicinski

Subject: Re: [PATCH] drivers/net/fjes: fix a potential NULL pointer dereference

On Wed, 18 Sep 2019 22:03:15 +0530, Allen Pais wrote:
> alloc_workqueue is not checked for errors and as a result,
> a potential NULL dereference could occur.
>
> Signed-off-by: Allen Pais <[email protected]>

If I'm looking at this right you are jumping to err_free_netdev without
setting the err variable. It must had been set to 0 from the return of
fjes_sw_init(). This means we will free the netdev, and return 0. This
means probe will not fail and driver's remove function will be run
at some point. fjes_remove it will try to free the netdev again.

Looks like there's another existing bug here in that the work queues
are not free when something fails in fjes_probe, just the netdev.

Once you untangle that, and before you post a v2, could you please try
to identify which commit introduced the regression and provide an
appropriate "Fixes" tag?

> diff --git a/drivers/net/fjes/fjes_main.c b/drivers/net/fjes/fjes_main.c
> index bbbc1dc..2d04104 100644
> --- a/drivers/net/fjes/fjes_main.c
> +++ b/drivers/net/fjes/fjes_main.c
> @@ -1237,8 +1237,15 @@ static int fjes_probe(struct platform_device *plat_dev)
> adapter->open_guard = false;
>
> adapter->txrx_wq = alloc_workqueue(DRV_NAME "/txrx", WQ_MEM_RECLAIM, 0);
> + if (unlikely(!adapter->txrx_wq))
> + goto err_free_netdev;
> +
> adapter->control_wq = alloc_workqueue(DRV_NAME "/control",
> WQ_MEM_RECLAIM, 0);
> + if (unlikely(!adapter->control_wq)) {
> + destroy_workqueue(adapter->txrx_wq);
> + goto err_free_netdev;
> + }
>
> INIT_WORK(&adapter->tx_stall_task, fjes_tx_stall_task);
> INIT_WORK(&adapter->raise_intr_rxdata_task,

2019-09-25 19:50:32

by Allen

Subject: Re: [PATCH] drivers/net/fjes: fix a potential NULL pointer dereference

>
> If I'm looking at this right you are jumping to err_free_netdev without
> setting the err variable. It must had been set to 0 from the return of
> fjes_sw_init(). This means we will free the netdev, and return 0. This
> means probe will not fail and driver's remove function will be run
> at some point. fjes_remove it will try to free the netdev again.

Good catch. Here's a quick diff what I should have done,

--- a/drivers/net/fjes/fjes_main.c
+++ b/drivers/net/fjes/fjes_main.c
@@ -1236,9 +1236,21 @@ static int fjes_probe(struct platform_device
*plat_dev)
adapter->force_reset = false;
adapter->open_guard = false;

+ /* Re-initialize err to -ENOMEM to handle workqueue allocation
failures,
+ and we don't return 0 on failure.
+ */
+ err = -ENOMEM;
+
adapter->txrx_wq = alloc_workqueue(DRV_NAME "/txrx",
WQ_MEM_RECLAIM, 0);
+ if (unlikely(!adapter->txrx_wq))
+ goto err_free_netdev;
+
adapter->control_wq = alloc_workqueue(DRV_NAME "/control",
WQ_MEM_RECLAIM, 0);
+ if (unlikely(!adapter->control_wq)) {
+ destroy_workqueue(adapter->txrx_wq);
+ goto err_free_netdev;
+ }


> Looks like there's another existing bug here in that the work queues
> are not free when something fails in fjes_probe, just the netdev.

I shall look into it and send out a separate fix.

> Once you untangle that, and before you post a v2, could you please try
> to identify which commit introduced the regression and provide an
> appropriate "Fixes" tag?
>

Fixes: f2edc4e1b078("net: fjes: fjes_main: Remove create_workqueue")

- Allen