Skip to contentSkip to conversation

Potentially invalid memory accesses in file drivers/mmc/core/block.c

DISCUSSION Shaobo 2 participants 4 messages Jul 22, 2017 – Aug 7, 2017 MMC, SD and SDIO

lore
Share & tools
lore

Shaobo

author
#0 lore raw

Hi there,

My name is Shaobo He and I am a graduate student at University of Utah. I am using a static analysis tool to search for null pointer dereferences and came across a couple of potentially invalid memory accesses in the file drivers/mmc/core/block.c: in function force_ro_store, function mmc_blk_get can return a NULL pointer. However, there are a couple of conditions that can make the error path infeasible. I was wondering if you could confirm this. Especially if the condition dev_to_disk(dev)->private_data && dev_to_disk(dev)->private_data->usage != 0 serves as a reasonable precondition of function force_ro_store.

Please let me know if it makes sense. I am looking forward to your reply.

Best,
Shaobo

#1 lore raw
Quoted 11 lines · Shaobo

My name is Shaobo He and I am a graduate student at University of Utah. I am using a static analysis tool to search for null pointer dereferences and came across a couple of potentially invalid memory accesses in the file drivers/mmc/core/block.c: in function force_ro_store, function mmc_blk_get can return a NULL pointer. However, there are a couple of conditions that can make the error path infeasible. I was wondering if you could confirm this. Especially if the condition dev_to_disk(dev)->private_data && dev_to_disk(dev)->private_data->usage != 0 serves as a reasonable precondition of function force_ro_store.

Please let me know if it makes sense. I am looking forward to your reply.

I can solidly confirm that the kernel is full och NULL pointer violations. But pointing out the problems is rarely helpful as that pushes the work of fixing them to others.

When you find specific cases, send patches to fix the issue to the respective subsystem maintainer(s). It is the best way to illustrate the problem you see and at the same time propose a solution.

You have reached the right list.

Yours,
Linus Walleij

author
#2 lore raw

Hi Linus,

Thanks for your reply. While I appreciate your suggestions, I'm a little confused because honestly I don't know if I was pointing out a real issue since the bug occurs under certain conditions. And my knowledge to decide if these conditions are feasible is very limited. That's the exact reason that the last email is for. If you could kindly confirm the issue in the last email, then I can probably come up with a reasonable fix.

Thanks again for your time and suggestions. Please let me know your thoughts.

Best,
Shaobo
-----Original Message-----
From: Linus Walleij [mailto:[email protected]]
Sent: 2017年8月3日 1:46
To: Shaobo <[email protected]>
Cc: [email protected]; Ulf Hansson <[email protected]>; Adrian Hunter <[email protected]>; Shawn Lin <[email protected]>; Jens Axboe <[email protected]>; Geert Uytterhoeven <[email protected]>
Subject: Re: Potentially invalid memory accesses in file drivers/mmc/core/block.c

Quoted 11 lines · Shaobo

My name is Shaobo He and I am a graduate student at University of
Utah. I am using a static analysis tool to search for null pointer
dereferences and came across a couple of potentially invalid memory
accesses in the file
drivers/mmc/core/block.c: in function force_ro_store, function
mmc_blk_get can return a NULL pointer. However, there are a couple
of conditions that can make the error path infeasible. I was wondering
if you could confirm this. Especially if the condition
`dev_to_disk(dev)->private_data &&
dev_to_disk(dev)->private_data->usage != 0 serves as a reasonable precondition of function force_ro_store`.

Quoted 1 line

Please let me know if it makes sense. I am looking forward to your reply.

I can solidly confirm that the kernel is full och NULL pointer violations.
But pointing out the problems is rarely helpful as that pushes the work of fixing them to others.

When you find specific cases, send patches to fix the issue to the respective subsystem maintainer(s). It is the best way to illustrate the problem you see and at the same time propose a solution.

You have reached the right list.

Yours,
Linus Walleij

#3 lore raw
Quoted 2 lines · Shaobo

Thanks for your reply. While I appreciate your suggestions, I'm a little confused because honestly I don't know if I was pointing out a real issue since the bug occurs under certain conditions.

If you can reproduce the bug, try fixing it and see if it goes away?

If it goes away you are likely right so just include the description with your patch.

I don't understand really.

Following the code flow as you have described it in verbatim text is too hard as it requires us to take out the code and scrutinize it while reading your mail.

It is much easier to read a patch, so please send a patch.

Yours,
Linus Walleij