Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix for BleedingTooth security vulnerability #12

Merged
merged 5 commits into from
Oct 15, 2020
Merged

Fix for BleedingTooth security vulnerability #12

merged 5 commits into from
Oct 15, 2020

Conversation

Flamefire
Copy link
Contributor

From https://twitter.com/theflow0/status/1316071793707364353 which links to https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00435.html

This applies the 4 of the 5 suggested patches, 4 of them are related (here the last 3).

Notes:

@Flamefire
Bluetooth: fix kernel oops in store_pending_adv_report
d01cb2d 
Fix kernel oops observed when an ext adv data is larger than 31 bytes.

This can be reproduced by setting up an advertiser with advertisement
larger than 31 bytes.  The issue is not sensitive to the advertisement
content.  In particular, this was reproduced with an advertisement of
229 bytes filled with 'A'.  See stack trace below.

This is fixed by not catching ext_adv as legacy adv are only cached to
be able to concatenate a scanable adv with its scan response before
sending it up through mgmt.

With ext_adv, this is no longer necessary.

Taken from https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=a2ec905d1e160a33b2e210e45ad30445ef26ce0e
By Linus Torvalds <torvalds@linux-foundation.org>

Change-Id: Iad1e016df8e034318c9bd197aaeae4ba712cc99f
@Flamefire
Bluetooth: Use BT_ERR_RATELIMITED instead of bt_dev_err_ratelimited
3e40cf9 
The latter is not yet available

Change-Id: I0ec2408def623145462541d8f76605882e45a2fe
@Flamefire
Bluetooth: A2MP: Fix not initializing all members
fa30ea3 
This fixes various places where a stack variable is used uninitialized.

Taken from https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
By Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Change-Id: I26912bad4c38f5c6078c802d90f1fd25f659ecba
@Flamefire
Bluetooth: Disable High Speed by default
9f69b5f 
Bluetooth High Speed requires hardware support which is very uncommon
nowadays since HS has not pickup interest by the industry.

From https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
By Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Change-Id: I9b731761667e940b664731a4372a2679f1d76613
@Flamefire
Bluetooth: MGMT: Fix not checking if BT_HS is enabled
1b14f27 
This checks if BT_HS is enabled relecting it on MGMT_SETTING_HS instead
of always reporting it as supported.

From https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
By Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

Change-Id: I8a622e760317ee0ae3e669911b0950e274f2859f
@derfelot
Copy link
Member

Thanks :)

While I don't see anything in these patches that should cause issues, have you verified different BT scenarios with them applied?

My use case is very limited, I only have BT speakers to test really.

@Flamefire
Copy link
Contributor Author

Not fully tested, but verified them manually to be the same as from the sources and I trust those committers. Also reviewed the changes and don't see any problems. Everything is straight forward correct.

@derfelot
Copy link
Member

lgtm

@derfelot derfelot merged commit ee7b7fb into whatawurst:lineage-17.1 Oct 15, 2020
j4nn pushed a commit to j4nn/android_kernel_sony_msm8998 that referenced this pull request Oct 15, 2020
@gregkh
tools lib traceevent: Fix memory leak in process_dynamic_array_len
bcd1c6a 
[ Upstream commit e24c644 ]

I compiled with AddressSanitizer and I had these memory leaks while I
was using the tep_parse_format function:

    Direct leak of 28 byte(s) in 4 object(s) allocated from:
        #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
        whatawurst#1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
        whatawurst#2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
        whatawurst#3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
        whatawurst#4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
        whatawurst#5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
        whatawurst#6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
        whatawurst#7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
        whatawurst#8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
        whatawurst#9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
        whatawurst#10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
        whatawurst#11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
        whatawurst#12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
        whatawurst#13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
        whatawurst#14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
        whatawurst#15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
        whatawurst#16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
        whatawurst#17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
        whatawurst#18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
        whatawurst#19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
        whatawurst#20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
        whatawurst#21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
        whatawurst#22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
        whatawurst#23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
        whatawurst#24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
        whatawurst#25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
        whatawurst#26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)

The token variable in the process_dynamic_array_len function is
allocated in the read_expect_type function, but is not freed before
calling the read_token function.

Free the token variable before calling read_token in order to plug the
leak.

Signed-off-by: Philippe Duplessis-Guindon <pduplessis@efficios.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
j4nn pushed a commit to j4nn/android_kernel_sony_msm8998 that referenced this pull request Oct 15, 2020
@namhyung @gregkh
perf test: Free formats for perf pmu parse test
4a35c69 
[ Upstream commit d26383d ]

The following leaks were detected by ASAN:

  Indirect leak of 360 byte(s) in 9 object(s) allocated from:
    #0 0x7fecc305180e in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10780e)
    whatawurst#1 0x560578f6dce5 in perf_pmu__new_format util/pmu.c:1333
    whatawurst#2 0x560578f752fc in perf_pmu_parse util/pmu.y:59
    whatawurst#3 0x560578f6a8b7 in perf_pmu__format_parse util/pmu.c:73
    whatawurst#4 0x560578e07045 in test__pmu tests/pmu.c:155
    whatawurst#5 0x560578de109b in run_test tests/builtin-test.c:410
    whatawurst#6 0x560578de109b in test_and_print tests/builtin-test.c:440
    whatawurst#7 0x560578de401a in __cmd_test tests/builtin-test.c:661
    whatawurst#8 0x560578de401a in cmd_test tests/builtin-test.c:807
    whatawurst#9 0x560578e49354 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:312
    whatawurst#10 0x560578ce71a8 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:364
    whatawurst#11 0x560578ce71a8 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:408
    whatawurst#12 0x560578ce71a8 in main /home/namhyung/project/linux/tools/perf/perf.c:538
    whatawurst#13 0x7fecc2b7acc9 in __libc_start_main ../csu/libc-start.c:308

Fixes: cff7f95 ("perf tests: Move pmu tests into separate object")
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Link: http://lore.kernel.org/lkml/20200915031819.386559-12-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@Flamefire Flamefire deleted the bt_sec_fix branch October 16, 2020 08:56
@Flamefire
Copy link
Contributor Author

FWIW: It seems Android is not actually affected by the security issues as it doesn't use BlueZ, according to current sources. However I don't think having the possible issues fixed here hurts

@derfelot
Copy link
Member

yeah, that's fine.

FYI, looks like 3 of these are now part of the 4.4.240 kernel release. I will revert those 3 to stay clean with upstream during merge.

@Flamefire
Copy link
Contributor Author

Great! Just wanted to have them in in case they don't backport them. By keeping the commits as-is it should be easy enough to find the included ones :)

@derfelot
Copy link
Member

derfelot commented Oct 17, 2020 •
edited

I stand corrected, 4/5 are included. They directly used pr_err_ratelimited("legacy adv larger than 31 bytes"); instead of bt_dev_err_ratelimited will leave the defconfig change as it is now

Amy07i pushed a commit to Amy07i/android_kernel_sony_msm8998 that referenced this pull request Jun 12, 2022
@suresh2514 @Amy07i
net-sysfs: add check for netdevice being present to speed_show
3abfcd9 
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]

When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.

    [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
    [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
    ...
    [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280

    crash> bt
    ...
    PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
    ...
     whatawurst#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
        [exception RIP: dma_pool_alloc+0x1ab]
        RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
        RAX: 0000000000000246  RBX: ffff89243d874100  RCX: 0000000000001000
        RDX: 0000000000000000  RSI: 0000000000000246  RDI: ffff89243d874090
        RBP: ffff89240e1a39c0   R8: 000000000001f080   R9: ffff8905ffc03c00
        R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12: 00000000000080d0
        R13: ffff89243d874090  R14: ffff89243d874080  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    whatawurst#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
    whatawurst#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
    whatawurst#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
    whatawurst#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
    whatawurst#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
    whatawurst#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
    whatawurst#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
    whatawurst#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
    whatawurst#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
    whatawurst#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
    whatawurst#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
    whatawurst#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
    whatawurst#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
    whatawurst#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
    whatawurst#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
    whatawurst#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
    whatawurst#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92

    crash> net_device.state ffff89443b0c0000
      state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)

To prevent this scenario, we also make sure that the netdevice is present.

Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Amy07i pushed a commit to Amy07i/android_kernel_sony_msm8998 that referenced this pull request Aug 10, 2022
@suresh2514 @pavelmachek
net-sysfs: add check for netdevice being present to speed_show
e575e5e 
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]

When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.

    [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
    [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
    ...
    [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280

    crash> bt
    ...
    PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
    ...
     whatawurst#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
        [exception RIP: dma_pool_alloc+0x1ab]
        RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
        RAX: 0000000000000246  RBX: ffff89243d874100  RCX: 0000000000001000
        RDX: 0000000000000000  RSI: 0000000000000246  RDI: ffff89243d874090
        RBP: ffff89240e1a39c0   R8: 000000000001f080   R9: ffff8905ffc03c00
        R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12: 00000000000080d0
        R13: ffff89243d874090  R14: ffff89243d874080  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    whatawurst#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
    whatawurst#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
    whatawurst#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
    whatawurst#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
    whatawurst#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
    whatawurst#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
    whatawurst#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
    whatawurst#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
    whatawurst#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
    whatawurst#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
    whatawurst#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
    whatawurst#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
    whatawurst#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
    whatawurst#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
    whatawurst#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
    whatawurst#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
    whatawurst#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92

    crash> net_device.state ffff89443b0c0000
      state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)

To prevent this scenario, we also make sure that the netdevice is present.

Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Amy07i pushed a commit to Amy07i/android_kernel_sony_msm8998 that referenced this pull request Aug 14, 2022
@Flamefire
Merge pull request whatawurst#12 from Flamefire/lineage-17.1-update
82913fc 
Lineage 18.1 update
ariffjenong pushed a commit to ariffjenong/android_kernel_sony_msm8998 that referenced this pull request Sep 4, 2022
@suresh2514 @ariffjenong
net-sysfs: add check for netdevice being present to speed_show
b2c5100 
[ Upstream commit 4224cfd7fb6523f7a9d1c8bb91bb5df1e38eb624 ]

When bringing down the netdevice or system shutdown, a panic can be
triggered while accessing the sysfs path because the device is already
removed.

    [  755.549084] mlx5_core 0000:12:00.1: Shutdown was called
    [  756.404455] mlx5_core 0000:12:00.0: Shutdown was called
    ...
    [  757.937260] BUG: unable to handle kernel NULL pointer dereference at           (null)
    [  758.031397] IP: [<ffffffff8ee11acb>] dma_pool_alloc+0x1ab/0x280

    crash> bt
    ...
    PID: 12649  TASK: ffff8924108f2100  CPU: 1   COMMAND: "amsd"
    ...
     whatawurst#9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778
        [exception RIP: dma_pool_alloc+0x1ab]
        RIP: ffffffff8ee11acb  RSP: ffff89240e1a3968  RFLAGS: 00010046
        RAX: 0000000000000246  RBX: ffff89243d874100  RCX: 0000000000001000
        RDX: 0000000000000000  RSI: 0000000000000246  RDI: ffff89243d874090
        RBP: ffff89240e1a39c0   R8: 000000000001f080   R9: ffff8905ffc03c00
        R10: ffffffffc04680d4  R11: ffffffff8edde9fd  R12: 00000000000080d0
        R13: ffff89243d874090  R14: ffff89243d874080  R15: 0000000000000000
        ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
    whatawurst#10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]
    whatawurst#11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]
    whatawurst#12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]
    whatawurst#13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]
    whatawurst#14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]
    whatawurst#15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]
    whatawurst#16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]
    whatawurst#17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46
    whatawurst#18 [ffff89240e1a3d48] speed_show at ffffffff8f277208
    whatawurst#19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3
    whatawurst#20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf
    whatawurst#21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596
    whatawurst#22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10
    whatawurst#23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5
    whatawurst#24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff
    whatawurst#25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f
    whatawurst#26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92

    crash> net_device.state ffff89443b0c0000
      state = 0x5  (__LINK_STATE_START| __LINK_STATE_NOCARRIER)

To prevent this scenario, we also make sure that the netdevice is present.

Signed-off-by: suresh kumar <suresh2514@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ariffjenong pushed a commit to ariffjenong/android_kernel_sony_msm8998 that referenced this pull request Jan 20, 2023
@liuhangbin
net/tunnel: wait until all sk_user_data reader finish before releasin…
9b99fe0 
…g the sock

[ Upstream commit 3cf7203ca620682165706f70a1b12b5194607dce ]

There is a race condition in vxlan that when deleting a vxlan device
during receiving packets, there is a possibility that the sock is
released after getting vxlan_sock vs from sk_user_data. Then in
later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got
NULL pointer dereference. e.g.

   #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757
   whatawurst#1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d
   whatawurst#2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48
   whatawurst#3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b
   whatawurst#4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb
   whatawurst#5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542
   whatawurst#6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62
      [exception RIP: vxlan_ecn_decapsulate+0x3b]
      RIP: ffffffffc1014e7b  RSP: ffffa25ec6978cb0  RFLAGS: 00010246
      RAX: 0000000000000008  RBX: ffff8aa000888000  RCX: 0000000000000000
      RDX: 000000000000000e  RSI: ffff8a9fc7ab803e  RDI: ffff8a9fd1168700
      RBP: ffff8a9fc7ab803e   R8: 0000000000700000   R9: 00000000000010ae
      R10: ffff8a9fcb748980  R11: 0000000000000000  R12: ffff8a9fd1168700
      R13: ffff8aa000888000  R14: 00000000002a0000  R15: 00000000000010ae
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
   whatawurst#7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]
   whatawurst#8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507
   whatawurst#9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45
  whatawurst#10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807
  whatawurst#11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951
  whatawurst#12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde
  whatawurst#13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b
  whatawurst#14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139
  whatawurst#15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a
  whatawurst#16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3
  whatawurst#17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca
  whatawurst#18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3

Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh

Fix this by waiting for all sk_user_data reader to finish before
releasing the sock.

Reported-by: Jianlin Shi <jishi@redhat.com>
Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Fixes: 6a93cc9 ("udp-tunnel: Add a few more UDP tunnel APIs")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
Amy07i pushed a commit to Amy07i/android_kernel_sony_msm8998 that referenced this pull request Jun 17, 2023
@tamird
ACPICA: Avoid undefined behavior: applying zero offset to null pointer
d5822e7 
[ Upstream commit 05bb0167c80b8f93c6a4e0451b7da9b96db990c2 ]

ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e

Before this change we see the following UBSAN stack trace in Fuchsia:

  #0    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  whatawurst#1.2  0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f
  whatawurst#1.1  0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f
  whatawurst#1    0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f
  whatawurst#2    0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d
  whatawurst#3    0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d
  whatawurst#4    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302
  whatawurst#5    0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369
  whatawurst#6    0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac
  whatawurst#7    0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2
  whatawurst#8    0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052
  whatawurst#9    0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8
  whatawurst#10   0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98
  whatawurst#11   0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac
  whatawurst#12   0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d
  whatawurst#13   0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603

Add a simple check that avoids incrementing a pointer by zero, but
otherwise behaves as before. Note that our findings are against ACPICA
20221020, but the same code exists on master.

Link: acpica/acpica@770653e3
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Ulrich Hecht <uli+cip@fpond.eu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@Flamefire @derfelot