[PATCH] bcache: safeguard a dangerous addressing in closure_queue

[PATCH] bcache: safeguard a dangerous addressing in closure_queue

[Liang Chen]

The use of the union reduces the size of closure struct by taking advantage
of the current size of its members. The offset of func in work_struct equals
the size of the first three members, so that work.work_func will just
reference the forth member - fn.

This is smart but dangerous. It can be broken if work_struct or the other
structs get changed, and can be a bit difficult to debug.

Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
---
Replacing all occurences of closure_fn to work_func_fn seems to be an option
but that would end up with a big lenghty and error prone patch.

 drivers/md/bcache/closure.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/md/bcache/closure.h b/drivers/md/bcache/closure.h
index 295b7e4..dbff8f4 100644
--- a/drivers/md/bcache/closure.h
+++ b/drivers/md/bcache/closure.h
@@ -251,6 +251,11 @@ static inline void set_closure_fn(struct closure *cl, closure_fn *fn,
 static inline void closure_queue(struct closure *cl)
 {
 	struct workqueue_struct *wq = cl->wq;
+	/**
+	 * Changes made to closure, work_struct, or a couple of other structs
+	 * may cause work.func not pointing to the right location.
+	 */
+	BUG_ON((unsigned long)cl->fn != (unsigned long)cl->work.func);
 	if (wq) {
 		INIT_WORK(&cl->work, cl->work.func);
 		BUG_ON(!queue_work(wq, &cl->work));
-- 
1.8.3.1

Re: [PATCH] bcache: safeguard a dangerous addressing in closure_queue

[Michael Lyle]

On 10/12/2017 07:37 AM, Liang Chen wrote:
> The use of the union reduces the size of closure struct by taking advantage
> of the current size of its members. The offset of func in work_struct equals
> the size of the first three members, so that work.work_func will just
> reference the forth member - fn.
> 
> This is smart but dangerous. It can be broken if work_struct or the other
> structs get changed, and can be a bit difficult to debug.
> 
> Signed-off-by: Liang Chen <liangchen.linux@gmail.com>

So the objective here is to make sure that struct work_struct and the
anonymous struct remain identical?  I agree that's a potential problem
for future maintenance.

Could we use BUILD_BUG_ON with offsets and sizes to do the same, to get
compile-time checking and avoid doing anything at runtime (I know the
compiler can usually omit the BUG but better to be safe)?  Otherwise a
kernel that triggered this problem would compile, and it'd only be if
someone actually used bcache that it would trigger.

Mike

Re: [PATCH] bcache: safeguard a dangerous addressing in closure_queue

[Liang Chen]

On Fri, Oct 13, 2017 at 1:44 AM, Michael Lyle <mlyle@lyle.org> wrote:
> On 10/12/2017 07:37 AM, Liang Chen wrote:
>> The use of the union reduces the size of closure struct by taking advantage
>> of the current size of its members. The offset of func in work_struct equals
>> the size of the first three members, so that work.work_func will just
>> reference the forth member - fn.
>>
>> This is smart but dangerous. It can be broken if work_struct or the other
>> structs get changed, and can be a bit difficult to debug.
>>
>> Signed-off-by: Liang Chen <liangchen.linux@gmail.com>
>
> So the objective here is to make sure that struct work_struct and the
> anonymous struct remain identical?  I agree that's a potential problem
> for future maintenance.
>
> Could we use BUILD_BUG_ON with offsets and sizes to do the same, to get
> compile-time checking and avoid doing anything at runtime (I know the
> compiler can usually omit the BUG but better to be safe)?  Otherwise a
> kernel that triggered this problem would compile, and it'd only be if
> someone actually used bcache that it would trigger.
>
> Mike

Yeah, the objective here is to make sure the offset of func and fn remains the
same so cl->work.func will just reference cl->fn.

Sure, BUILD_BUG_ON will do the work, and can capture the problem at compile
time. Thanks for the reminding! I will submit another patch soon.

Thanks,
Liang