On Thu 07-03-19 17:46:50, Pi-Hsun Shih wrote:
> Use offsetof to calculate offset of a field to avoid UBSAN warning like:
> 
> ===================================================================
> UBSAN: Undefined behaviour in mm/swapfile.c:3010:38
> member access within null pointer of type 'union swap_header'
> CPU: 6 PID: 1833 Comm: swapon Tainted: G S                4.19.23 #43
> Call trace:
>  dump_backtrace+0x0/0x194
>  show_stack+0x20/0x2c
>  __dump_stack+0x20/0x28
>  dump_stack+0x70/0x94
>  ubsan_epilogue+0x14/0x44
>  ubsan_type_mismatch_common+0xf4/0xfc
>  __ubsan_handle_type_mismatch_v1+0x34/0x54
>  __se_sys_swapon+0x654/0x1084
>  __arm64_sys_swapon+0x1c/0x24
>  el0_svc_common+0xa8/0x150
>  el0_svc_compat_handler+0x2c/0x38
>  el0_svc_compat+0x8/0x18
> ==================================================================

Could you be more specific about what exactly is undefined here and
why offsetof is any better. AFAIR it uses the same construct unless a
compiler defines a built in.

I do not object the change itself because it is cleaner to use the
existing helper but I am wondering why this is fixing ubsan. Is ubsan
defining the compiler variant and consider it safe?

> 
> Signed-off-by: Pi-Hsun Shih <[email protected]>
> ---
>  include/linux/swap.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/swap.h b/include/linux/swap.h
> index fc50e21b3b88..4bfb5c4ac108 100644
> --- a/include/linux/swap.h
> +++ b/include/linux/swap.h
> @@ -157,9 +157,9 @@ struct swap_extent {
>  /*
>   * Max bad pages in the new format..
>   */
> -#define __swapoffset(x) ((unsigned long)&((union swap_header *)0)->x)
>  #define MAX_SWAP_BADPAGES \
> -     ((__swapoffset(magic.magic) - __swapoffset(info.badpages)) / 
> sizeof(int))
> +     ((offsetof(union swap_header, magic.magic) - \
> +       offsetof(union swap_header, info.badpages)) / sizeof(int))
>  
>  enum {
>       SWP_USED        = (1 << 0),     /* is slot in swap_info[] used? */
> -- 
> 2.21.0.352.gf09ad66450-goog
> 

-- 
Michal Hocko
SUSE Labs

Reply via email to