[PATCH] staging: rtl8192u: r8192U_core.c: Fix for possible null pointer dereference

[PATCH] staging: rtl8192u: r8192U_core.c: Fix for possible null pointer dereference

[Rickard Strandqvist]

There is otherwise a risk of a possible null pointer dereference.

Was largely found by using a static code analysis program called cppcheck.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
 drivers/staging/rtl8192u/r8192U_core.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c b/drivers/staging/rtl8192u/r8192U_core.c
index 1bb6143..7bd58ee 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -2038,9 +2038,9 @@ static int WDCAPARA_ADD[] = {EDCAPARA_BE, EDCAPARA_BK, EDCAPARA_VI, EDCAPARA_VO}
 static void rtl8192_qos_activate(struct work_struct *work)
 {
 	struct r8192_priv *priv = container_of(work, struct r8192_priv, qos_activate);
-	struct net_device *dev = priv->ieee80211->dev;
-	struct ieee80211_qos_parameters *qos_parameters = &priv->ieee80211->current_network.qos_data.parameters;
-	u8 mode = priv->ieee80211->current_network.mode;
+	struct net_device *dev;
+	struct ieee80211_qos_parameters *qos_parameters;
+	u8 mode;
 	u8  u1bAIFS;
 	u32 u4bAcParam;
 	int i;
@@ -2048,6 +2048,10 @@ static void rtl8192_qos_activate(struct work_struct *work)
 	if (priv == NULL)
 		return;
 
+	dev = priv->ieee80211->dev;
+	qos_parameters = &priv->ieee80211->current_network.qos_data.parameters;
+	mode = priv->ieee80211->current_network.mode;
+
 	mutex_lock(&priv->mutex);
 	if (priv->ieee80211->state != IEEE80211_LINKED)
 		goto success;
-- 
1.7.10.4

Re: [PATCH] staging: rtl8192u: r8192U_core.c: Fix for possible null pointer dereference

[Dan Carpenter]

On Tue, May 20, 2014 at 11:32:53PM +0200, Rickard Strandqvist wrote:
> There is otherwise a risk of a possible null pointer dereference.
> 
> Was largely found by using a static code analysis program called cppcheck.
> 

Could you mention in the change log which pointer you are worried about?

I think you are concerned about "priv" here.  "priv" comes from
container_of() and checking the return value of container_of() doesn't
make sense.  It does some pointer math so even if "work" is NULL the
"priv" pointer would be non-zero.

Just remove the check.

regards,
dan carpenter