-
Notifications
You must be signed in to change notification settings - Fork 72
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.
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
Fix for BleedingTooth security vulnerability #12
Conversation
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
The latter is not yet available Change-Id: I0ec2408def623145462541d8f76605882e45a2fe
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
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
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
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. |
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. |
lgtm |
[ 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>
[ 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>
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 |
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. |
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 :) |
I stand corrected, 4/5 are included. They directly used |
[ 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>
[ 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>
Lineage 18.1 update
[ 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>
…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>
[ 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>
[ Upstream commit f8bbc07ac535593139c875ffa19af924b1084540 ] vhost_worker will call tun call backs to receive packets. If too many illegal packets arrives, tun_do_read will keep dumping packet contents. When console is enabled, it will costs much more cpu time to dump packet and soft lockup will be detected. net_ratelimit mechanism can be used to limit the dumping rate. PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 whatawurst#1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 whatawurst#2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e whatawurst#3 [fffffe00003fced0] do_nmi at ffffffff8922660d whatawurst#4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 whatawurst#5 [ffffa655314979e8] io_serial_in at ffffffff89792594 whatawurst#6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 whatawurst#7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 whatawurst#8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 whatawurst#9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 whatawurst#10 [ffffa65531497ac8] console_unlock at ffffffff89316124 whatawurst#11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 whatawurst#12 [ffffa65531497b68] printk at ffffffff89318306 whatawurst#13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 whatawurst#14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] whatawurst#15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] whatawurst#16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] whatawurst#17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] whatawurst#18 [ffffa65531497f10] kthread at ffffffff892d2e72 whatawurst#19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f Fixes: ef3db4a ("tun: avoid BUG, dump packet on GSO errors") Signed-off-by: Lei Chen <lei.chen@smartx.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Acked-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://lore.kernel.org/r/20240415020247.2207781-1-lei.chen@smartx.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> [uli: backport to 4.4] Signed-off-by: Ulrich Hecht <uli@kernel.org>
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:
sk_filter
is not used in this kernel version (yet?)hci_le_ext_adv_report_evt
missing in this kernel version. This makes the newly introducedext_adv
parameter superflous (always false) but I kept it as it doesn't hurt and allows for easier resolving conflicts if this kernel is updated from upstream