3.18 utf8 #249

darcyg · 2016-01-18T10:41:57Z

No description provided.

Original implementation commit e54bcde ("arm64: eBPF JIT compiler") had the relevant code paths, but due to an oversight always fail jiting. As a result, we had been falling back to BPF interpreter whenever a BPF program has JMP_JSET_{X,K} instructions. With this fix, we confirm that the corresponding tests in lib/test_bpf continue to pass, and also jited. ... [ 2.784553] test_bpf: #30 JSET jited:1 188 192 197 PASS [ 2.791373] test_bpf: #31 tcpdump port 22 jited:1 325 677 625 PASS [ 2.808800] test_bpf: #32 tcpdump complex jited:1 323 731 991 PASS ... [ 3.190759] test_bpf: #237 JMP_JSET_K: if (0x3 & 0x2) return 1 jited:1 110 PASS [ 3.192524] test_bpf: #238 JMP_JSET_K: if (0x3 & 0xffffffff) return 1 jited:1 98 PASS [ 3.211014] test_bpf: #249 JMP_JSET_X: if (0x3 & 0x2) return 1 jited:1 120 PASS [ 3.212973] test_bpf: #250 JMP_JSET_X: if (0x3 & 0xffffffff) return 1 jited:1 89 PASS ... Fixes: e54bcde ("arm64: eBPF JIT compiler") Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Yang Shi <yang.shi@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>

Original implementation commit e54bcde ("arm64: eBPF JIT compiler") had the relevant code paths, but due to an oversight always fail jiting. As a result, we had been falling back to BPF interpreter whenever a BPF program has JMP_JSET_{X,K} instructions. With this fix, we confirm that the corresponding tests in lib/test_bpf continue to pass, and also jited. ... [ 2.784553] test_bpf: torvalds#30 JSET jited:1 188 192 197 PASS [ 2.791373] test_bpf: torvalds#31 tcpdump port 22 jited:1 325 677 625 PASS [ 2.808800] test_bpf: torvalds#32 tcpdump complex jited:1 323 731 991 PASS ... [ 3.190759] test_bpf: torvalds#237 JMP_JSET_K: if (0x3 & 0x2) return 1 jited:1 110 PASS [ 3.192524] test_bpf: torvalds#238 JMP_JSET_K: if (0x3 & 0xffffffff) return 1 jited:1 98 PASS [ 3.211014] test_bpf: torvalds#249 JMP_JSET_X: if (0x3 & 0x2) return 1 jited:1 120 PASS [ 3.212973] test_bpf: torvalds#250 JMP_JSET_X: if (0x3 & 0xffffffff) return 1 jited:1 89 PASS ... Fixes: e54bcde ("arm64: eBPF JIT compiler") Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Yang Shi <yang.shi@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>

Currently we call copy_page_to_iter() for uncached reading into a pipe. This is wrong because it treats pages as VFS cache pages and copies references rather than actual data. When we are trying to read from the pipe we end up calling page_cache_pipe_buf_confirm() which returns -ENODATA. This error is translated into 0 which is returned to a user. This issue is reproduced by running xfs-tests suite (generic test torvalds#249) against mount points with "cache=none". Fix it by mapping pages manually and calling copy_to_iter() that copies data into the pipe. Cc: Stable <stable@vger.kernel.org> Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>

Merge linux 4.8

Currently we call copy_page_to_iter() for uncached reading into a pipe. This is wrong because it treats pages as VFS cache pages and copies references rather than actual data. When we are trying to read from the pipe we end up calling page_cache_pipe_buf_confirm() which returns -ENODATA. This error is translated into 0 which is returned to a user. This issue is reproduced by running xfs-tests suite (generic test torvalds#249) against mount points with "cache=none". Fix it by mapping pages manually and calling copy_to_iter() that copies data into the pipe. Cc: Stable <stable@vger.kernel.org> Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>

Since d2852a2 ("arch: add ARCH_HAS_SET_MEMORY config") and 9d876e7 ("bpf: fix unlocking of jited image when module ronx not set") that uses the former, Fengguang reported random corruptions on his i386 test machine [1]. On i386 there is no JIT available, and since his kernel config doesn't have kernel modules enabled, there was also no DEBUG_SET_MODULE_RONX enabled before which would set interpreted bpf_prog image as read-only like we do in various other cases for quite some time now, e.g. x86_64, arm64, etc. Thus, the difference with above commits was that we now used set_memory_ro() and set_memory_rw() on i386, which resulted in these issues. When reproducing this with Fengguang's config and qemu image, I changed lib/test_bpf.c to be run during boot instead of relying on trinity to fiddle with cBPF. The issues I saw with the BPF test suite when set_memory_ro() and set_memory_rw() is used to write protect image on i386 is that after a number of tests I noticed a corruption happening in bpf_prog_realloc(). Specifically, fp_old's content gets corrupted right *after* the (unrelated) __vmalloc() call and contains only zeroes right after the call instead of the original prog data. fp_old should have been freed later on via __bpf_prog_free() *after* we copied all the data over to the newly allocated fp. Result looks like: [...] [ 13.107240] test_bpf: torvalds#249 JMP_JSET_X: if (0x3 & 0x2) return 1 jited:0 17 PASS [ 13.108182] test_bpf: torvalds#250 JMP_JSET_X: if (0x3 & 0xffffffff) return 1 jited:0 17 PASS [ 13.109206] test_bpf: torvalds#251 JMP_JA: Jump, gap, jump, ... jited:0 16 PASS [ 13.110493] test_bpf: torvalds#252 BPF_MAXINSNS: Maximum possible literals jited:0 12 PASS [ 13.111885] test_bpf: torvalds#253 BPF_MAXINSNS: Single literal jited:0 8 PASS [ 13.112804] test_bpf: torvalds#254 BPF_MAXINSNS: Run/add until end jited:0 6341 PASS [ 13.177195] test_bpf: torvalds#255 BPF_MAXINSNS: Too many instructions PASS [ 13.177689] test_bpf: torvalds#256 BPF_MAXINSNS: Very long jump jited:0 9 PASS [ 13.178611] test_bpf: torvalds#257 BPF_MAXINSNS: Ctx heavy transformations [ 13.178713] BUG: unable to handle kernel NULL pointer dereference at 00000034 [ 13.179740] IP: bpf_prog_realloc+0x5b/0x90 [ 13.180017] *pde = 00000000 [ 13.180017] [ 13.180017] Oops: 0002 [#1] DEBUG_PAGEALLOC [ 13.180017] CPU: 0 PID: 1 Comm: swapper Not tainted 4.10.0-57268-gd627975-dirty torvalds#50 [ 13.180017] task: 401ec000 task.stack: 401f2000 [ 13.180017] EIP: bpf_prog_realloc+0x5b/0x90 [ 13.180017] EFLAGS: 00210246 CPU: 0 [ 13.180017] EAX: 00000000 EBX: 57ae1000 ECX: 00000000 EDX: 57ae1000 [ 13.180017] ESI: 00000019 EDI: 57b07000 EBP: 401f3e74 ESP: 401f3e68 [ 13.180017] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [ 13.180017] CR0: 80050033 CR2: 00000034 CR3: 12cb1000 CR4: 00000610 [ 13.180017] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 [ 13.180017] DR6: fffe0ff0 DR7: 00000400 [ 13.180017] Call Trace: [ 13.180017] bpf_prepare_filter+0x317/0x3a0 [ 13.180017] bpf_prog_create+0x65/0xa0 [ 13.180017] test_bpf_init+0x1ca/0x628 [ 13.180017] ? test_hexdump_init+0xb5/0xb5 [ 13.180017] do_one_initcall+0x7c/0x11c [...] When using trinity from Fengguang's reproducer, the corruptions were at inconsistent places, presumably from code dealing with allocations and seeing similar effects as mentioned above. Not using set_memory_ro() and set_memory_rw() lets the test suite run just fine as expected, thus it looks like using set_memory_*() on i386 seems broken and mentioned commits just uncovered it. Also, for checking, I enabled DEBUG_RODATA_TEST for that kernel. Latter shows that memory protecting the kernel seems not working either on i386 (!). Test suite output: [...] [ 12.692836] Write protecting the kernel text: 13416k [ 12.693309] Write protecting the kernel read-only data: 5292k [ 12.693802] rodata_test: test data was not read only [...] Work-around to not enable ARCH_HAS_SET_MEMORY for i386 is not optimal as it doesn't fix the issue in presumably broken set_memory_*(), but it at least avoids people avoid having to deal with random corruptions that are hard to track down for the time being until a real fix can be found. [1] https://lkml.org/lkml/2017/3/2/648 Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Laura Abbott <labbott@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Alexei Starovoitov <ast@kernel.org>

KASAN detected a use-after-free: [ 269.467067] BUG: KASAN: use-after-free in vrf_xmit+0x7f1/0x827 [vrf] at addr ffff8800350a21c0 [ 269.467067] Read of size 4 by task ssh/1879 [ 269.467067] CPU: 1 PID: 1879 Comm: ssh Not tainted 4.10.0+ torvalds#249 [ 269.467067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 269.467067] Call Trace: [ 269.467067] dump_stack+0x81/0xb6 [ 269.467067] kasan_object_err+0x21/0x78 [ 269.467067] kasan_report+0x2f7/0x450 [ 269.467067] ? vrf_xmit+0x7f1/0x827 [vrf] [ 269.467067] ? ip_output+0xa4/0xdb [ 269.467067] __asan_load4+0x6b/0x6d [ 269.467067] vrf_xmit+0x7f1/0x827 [vrf] ... Which corresponds to the skb access after xmit handling. Fix by saving skb->len and using the saved value to update stats. Fixes: 193125d ("net: Introduce VRF device driver") Signed-off-by: David Ahern <dsa@cumulusnetworks.com>

KASAN detected a use-after-free: [ 269.467067] BUG: KASAN: use-after-free in vrf_xmit+0x7f1/0x827 [vrf] at addr ffff8800350a21c0 [ 269.467067] Read of size 4 by task ssh/1879 [ 269.467067] CPU: 1 PID: 1879 Comm: ssh Not tainted 4.10.0+ torvalds#249 [ 269.467067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 269.467067] Call Trace: [ 269.467067] dump_stack+0x81/0xb6 [ 269.467067] kasan_object_err+0x21/0x78 [ 269.467067] kasan_report+0x2f7/0x450 [ 269.467067] ? vrf_xmit+0x7f1/0x827 [vrf] [ 269.467067] ? ip_output+0xa4/0xdb [ 269.467067] __asan_load4+0x6b/0x6d [ 269.467067] vrf_xmit+0x7f1/0x827 [vrf] ... Which corresponds to the skb access after xmit handling. Fix by saving skb->len and using the saved value to update stats. Fixes: 193125d ("net: Introduce VRF device driver") Signed-off-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net>

commit 9c25702 upstream. Currently we call copy_page_to_iter() for uncached reading into a pipe. This is wrong because it treats pages as VFS cache pages and copies references rather than actual data. When we are trying to read from the pipe we end up calling page_cache_pipe_buf_confirm() which returns -ENODATA. This error is translated into 0 which is returned to a user. This issue is reproduced by running xfs-tests suite (generic test torvalds#249) against mount points with "cache=none". Fix it by mapping pages manually and calling copy_to_iter() that copies data into the pipe. Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 9c25702 upstream. Currently we call copy_page_to_iter() for uncached reading into a pipe. This is wrong because it treats pages as VFS cache pages and copies references rather than actual data. When we are trying to read from the pipe we end up calling page_cache_pipe_buf_confirm() which returns -ENODATA. This error is translated into 0 which is returned to a user. This issue is reproduced by running xfs-tests suite (generic test #249) against mount points with "cache=none". Fix it by mapping pages manually and calling copy_to_iter() that copies data into the pipe. Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit f7887d4 ] KASAN detected a use-after-free: [ 269.467067] BUG: KASAN: use-after-free in vrf_xmit+0x7f1/0x827 [vrf] at addr ffff8800350a21c0 [ 269.467067] Read of size 4 by task ssh/1879 [ 269.467067] CPU: 1 PID: 1879 Comm: ssh Not tainted 4.10.0+ torvalds#249 [ 269.467067] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 269.467067] Call Trace: [ 269.467067] dump_stack+0x81/0xb6 [ 269.467067] kasan_object_err+0x21/0x78 [ 269.467067] kasan_report+0x2f7/0x450 [ 269.467067] ? vrf_xmit+0x7f1/0x827 [vrf] [ 269.467067] ? ip_output+0xa4/0xdb [ 269.467067] __asan_load4+0x6b/0x6d [ 269.467067] vrf_xmit+0x7f1/0x827 [vrf] ... Which corresponds to the skb access after xmit handling. Fix by saving skb->len and using the saved value to update stats. Fixes: 193125d ("net: Introduce VRF device driver") Signed-off-by: David Ahern <dsa@cumulusnetworks.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a big batch of test coverage to assert all aspects of the tcx opts attach, detach and query API: # ./vmtest.sh -- ./test_progs -t tc_opts [...] torvalds#238 tc_opts_after:OK torvalds#239 tc_opts_append:OK torvalds#240 tc_opts_basic:OK torvalds#241 tc_opts_before:OK torvalds#242 tc_opts_chain_classic:OK torvalds#243 tc_opts_demixed:OK torvalds#244 tc_opts_detach:OK torvalds#245 tc_opts_detach_after:OK torvalds#246 tc_opts_detach_before:OK torvalds#247 tc_opts_dev_cleanup:OK torvalds#248 tc_opts_invalid:OK torvalds#249 tc_opts_mixed:OK torvalds#250 tc_opts_prepend:OK torvalds#251 tc_opts_replace:OK torvalds#252 tc_opts_revision:OK Summary: 15/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add a big batch of test coverage to assert all aspects of the tcx opts attach, detach and query API: # ./vmtest.sh -- ./test_progs -t tc_opts [...] torvalds#238 tc_opts_after:OK torvalds#239 tc_opts_append:OK torvalds#240 tc_opts_basic:OK torvalds#241 tc_opts_before:OK torvalds#242 tc_opts_chain_classic:OK torvalds#243 tc_opts_demixed:OK torvalds#244 tc_opts_detach:OK torvalds#245 tc_opts_detach_after:OK torvalds#246 tc_opts_detach_before:OK torvalds#247 tc_opts_dev_cleanup:OK torvalds#248 tc_opts_invalid:OK torvalds#249 tc_opts_mixed:OK torvalds#250 tc_opts_prepend:OK torvalds#251 tc_opts_replace:OK torvalds#252 tc_opts_revision:OK Summary: 15/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20230719140858.13224-8-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>

Add a detachment test case with miniq present to assert that with and without the miniq we get the same error. # ./test_progs -t tc_opts torvalds#244 tc_opts_after:OK torvalds#245 tc_opts_append:OK torvalds#246 tc_opts_basic:OK torvalds#247 tc_opts_before:OK torvalds#248 tc_opts_chain_classic:OK torvalds#249 tc_opts_delete_empty:OK torvalds#250 tc_opts_demixed:OK torvalds#251 tc_opts_detach:OK torvalds#252 tc_opts_detach_after:OK torvalds#253 tc_opts_detach_before:OK torvalds#254 tc_opts_dev_cleanup:OK torvalds#255 tc_opts_invalid:OK torvalds#256 tc_opts_mixed:OK torvalds#257 tc_opts_prepend:OK torvalds#258 tc_opts_replace:OK torvalds#259 tc_opts_revision:OK Summary: 16/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add a detachment test case with miniq present to assert that with and without the miniq we get the same error. # ./test_progs -t tc_opts torvalds#244 tc_opts_after:OK torvalds#245 tc_opts_append:OK torvalds#246 tc_opts_basic:OK torvalds#247 tc_opts_before:OK torvalds#248 tc_opts_chain_classic:OK torvalds#249 tc_opts_delete_empty:OK torvalds#250 tc_opts_demixed:OK torvalds#251 tc_opts_detach:OK torvalds#252 tc_opts_detach_after:OK torvalds#253 tc_opts_detach_before:OK torvalds#254 tc_opts_dev_cleanup:OK torvalds#255 tc_opts_invalid:OK torvalds#256 tc_opts_mixed:OK torvalds#257 tc_opts_prepend:OK torvalds#258 tc_opts_replace:OK torvalds#259 tc_opts_revision:OK Summary: 16/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/20230804131112.11012-2-daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>

[...] torvalds#234 tc_links_after:OK torvalds#235 tc_links_append:OK torvalds#236 tc_links_basic:OK torvalds#237 tc_links_before:OK torvalds#238 tc_links_chain_classic:OK torvalds#239 tc_links_chain_mixed:OK torvalds#240 tc_links_dev_cleanup:OK torvalds#241 tc_links_ingress:OK torvalds#242 tc_links_invalid:OK torvalds#243 tc_links_prepend:OK torvalds#244 tc_links_replace:OK torvalds#245 tc_links_revision:OK torvalds#246 tc_opts_after:OK torvalds#247 tc_opts_append:OK torvalds#248 tc_opts_basic:OK torvalds#249 tc_opts_before:OK torvalds#250 tc_opts_chain_classic:OK torvalds#251 tc_opts_chain_mixed:OK torvalds#252 tc_opts_delete_empty:OK torvalds#253 tc_opts_demixed:OK torvalds#254 tc_opts_detach:OK torvalds#255 tc_opts_detach_after:OK torvalds#256 tc_opts_detach_before:OK torvalds#257 tc_opts_dev_cleanup:OK torvalds#258 tc_opts_invalid:OK torvalds#259 tc_opts_mixed:OK torvalds#260 tc_opts_prepend:OK torvalds#261 tc_opts_replace:OK torvalds#262 tc_opts_revision:OK [...] Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add several new tcx test cases to improve test coverage. This also includes a few new tests with ingress instead of clsact qdisc, to cover the fix from commit dc644b5 ("tcx: Fix splat in ingress_destroy upon tcx_entry_free"). # ./test_progs -t tc [...] torvalds#234 tc_links_after:OK torvalds#235 tc_links_append:OK torvalds#236 tc_links_basic:OK torvalds#237 tc_links_before:OK torvalds#238 tc_links_chain_classic:OK torvalds#239 tc_links_chain_mixed:OK torvalds#240 tc_links_dev_cleanup:OK torvalds#241 tc_links_dev_mixed:OK torvalds#242 tc_links_ingress:OK torvalds#243 tc_links_invalid:OK torvalds#244 tc_links_prepend:OK torvalds#245 tc_links_replace:OK torvalds#246 tc_links_revision:OK torvalds#247 tc_opts_after:OK torvalds#248 tc_opts_append:OK torvalds#249 tc_opts_basic:OK torvalds#250 tc_opts_before:OK torvalds#251 tc_opts_chain_classic:OK torvalds#252 tc_opts_chain_mixed:OK torvalds#253 tc_opts_delete_empty:OK torvalds#254 tc_opts_demixed:OK torvalds#255 tc_opts_detach:OK torvalds#256 tc_opts_detach_after:OK torvalds#257 tc_opts_detach_before:OK torvalds#258 tc_opts_dev_cleanup:OK torvalds#259 tc_opts_invalid:OK torvalds#260 tc_opts_mixed:OK torvalds#261 tc_opts_prepend:OK torvalds#262 tc_opts_replace:OK torvalds#263 tc_opts_revision:OK [...] Summary: 44/38 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>

Add several new tcx test cases to improve test coverage. This also includes a few new tests with ingress instead of clsact qdisc, to cover the fix from commit dc644b5 ("tcx: Fix splat in ingress_destroy upon tcx_entry_free"). # ./test_progs -t tc [...] torvalds#234 tc_links_after:OK torvalds#235 tc_links_append:OK torvalds#236 tc_links_basic:OK torvalds#237 tc_links_before:OK torvalds#238 tc_links_chain_classic:OK torvalds#239 tc_links_chain_mixed:OK torvalds#240 tc_links_dev_cleanup:OK torvalds#241 tc_links_dev_mixed:OK torvalds#242 tc_links_ingress:OK torvalds#243 tc_links_invalid:OK torvalds#244 tc_links_prepend:OK torvalds#245 tc_links_replace:OK torvalds#246 tc_links_revision:OK torvalds#247 tc_opts_after:OK torvalds#248 tc_opts_append:OK torvalds#249 tc_opts_basic:OK torvalds#250 tc_opts_before:OK torvalds#251 tc_opts_chain_classic:OK torvalds#252 tc_opts_chain_mixed:OK torvalds#253 tc_opts_delete_empty:OK torvalds#254 tc_opts_demixed:OK torvalds#255 tc_opts_detach:OK torvalds#256 tc_opts_detach_after:OK torvalds#257 tc_opts_detach_before:OK torvalds#258 tc_opts_dev_cleanup:OK torvalds#259 tc_opts_invalid:OK torvalds#260 tc_opts_mixed:OK torvalds#261 tc_opts_prepend:OK torvalds#262 tc_opts_replace:OK torvalds#263 tc_opts_revision:OK [...] Summary: 44/38 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/r/8699efc284b75ccdc51ddf7062fa2370330dc6c0.1692029283.git.daniel@iogearbox.net Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>

On powerpc64, you can build a kernel with KASAN as soon as you build it with RADIX MMU support. However if the CPU doesn't have RADIX MMU, KASAN isn't enabled at init and the following Oops is encountered. [ 0.000000][ T0] KASAN not enabled as it requires radix! [ 4.484295][ T26] BUG: Unable to handle kernel data access at 0xc00e000000804a04 [ 4.485270][ T26] Faulting instruction address: 0xc00000000062ec6c [ 4.485748][ T26] Oops: Kernel access of bad area, sig: 11 [#1] [ 4.485920][ T26] BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries [ 4.486259][ T26] Modules linked in: [ 4.486637][ T26] CPU: 0 PID: 26 Comm: kworker/u2:2 Not tainted 6.2.0-rc3-02590-gf8a023b0a805 torvalds#249 [ 4.486907][ T26] Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1200 0xf000005 of:SLOF,HEAD pSeries [ 4.487445][ T26] Workqueue: eval_map_wq .tracer_init_tracefs_work_func [ 4.488744][ T26] NIP: c00000000062ec6c LR: c00000000062bb84 CTR: c0000000002ebcd0 [ 4.488867][ T26] REGS: c0000000049175c0 TRAP: 0380 Not tainted (6.2.0-rc3-02590-gf8a023b0a805) [ 4.489028][ T26] MSR: 8000000002009032 <SF,VEC,EE,ME,IR,DR,RI> CR: 44002808 XER: 00000000 [ 4.489584][ T26] CFAR: c00000000062bb80 IRQMASK: 0 [ 4.489584][ T26] GPR00: c0000000005624d4 c000000004917860 c000000001cfc000 1800000000804a04 [ 4.489584][ T26] GPR04: c0000000003a2650 0000000000000cc0 c00000000000d3d8 c00000000000d3d8 [ 4.489584][ T26] GPR08: c0000000049175b0 a80e000000000000 0000000000000000 0000000017d78400 [ 4.489584][ T26] GPR12: 0000000044002204 c000000003790000 c00000000435003c c0000000043f1c40 [ 4.489584][ T26] GPR16: c0000000043f1c68 c0000000043501a0 c000000002106138 c0000000043f1c08 [ 4.489584][ T26] GPR20: c0000000043f1c10 c0000000043f1c20 c000000004146c40 c000000002fdb7f8 [ 4.489584][ T26] GPR24: c000000002fdb834 c000000003685e00 c000000004025030 c000000003522e90 [ 4.489584][ T26] GPR28: 0000000000000cc0 c0000000003a2650 c000000004025020 c000000004025020 [ 4.491201][ T26] NIP [c00000000062ec6c] .kasan_byte_accessible+0xc/0x20 [ 4.491430][ T26] LR [c00000000062bb84] .__kasan_check_byte+0x24/0x90 [ 4.491767][ T26] Call Trace: [ 4.491941][ T26] [c000000004917860] [c00000000062ae70] .__kasan_kmalloc+0xc0/0x110 (unreliable) [ 4.492270][ T26] [c0000000049178f0] [c0000000005624d4] .krealloc+0x54/0x1c0 [ 4.492453][ T26] [c000000004917990] [c0000000003a2650] .create_trace_option_files+0x280/0x530 [ 4.492613][ T26] [c000000004917a90] [c000000002050d90] .tracer_init_tracefs_work_func+0x274/0x2c0 [ 4.492771][ T26] [c000000004917b40] [c0000000001f9948] .process_one_work+0x578/0x9f0 [ 4.492927][ T26] [c000000004917c30] [c0000000001f9ebc] .worker_thread+0xfc/0x950 [ 4.493084][ T26] [c000000004917d60] [c00000000020be84] .kthread+0x1a4/0x1b0 [ 4.493232][ T26] [c000000004917e10] [c00000000000d3d8] .ret_from_kernel_thread+0x58/0x60 [ 4.495642][ T26] Code: 60000000 7cc802a6 38a00000 4bfffc78 60000000 7cc802a6 38a00001 4bfffc68 60000000 3d20a80e 7863e8c2 792907c6 <7c6348ae> 20630007 78630fe0 68630001 [ 4.496704][ T26] ---[ end trace 0000000000000000 ]--- The Oops is due to kasan_byte_accessible() not checking the readiness of KASAN. Add missing call to kasan_arch_is_ready() and bail out when not ready. The same problem is observed with ____kasan_kfree_large() so fix it the same. Also, as KASAN is not available and no shadow area is allocated for linear memory mapping, there is no point in allocating shadow mem for vmalloc memory as shown below in /sys/kernel/debug/kernel_page_tables ---[ kasan shadow mem start ]--- 0xc00f000000000000-0xc00f00000006ffff 0x00000000040f0000 448K r w pte valid present dirty accessed 0xc00f000000860000-0xc00f00000086ffff 0x000000000ac10000 64K r w pte valid present dirty accessed 0xc00f3ffffffe0000-0xc00f3fffffffffff 0x0000000004d10000 128K r w pte valid present dirty accessed ---[ kasan shadow mem end ]--- So, also verify KASAN readiness before allocating and poisoning shadow mem for VMAs. Link: https://lkml.kernel.org/r/150768c55722311699fdcf8f5379e8256749f47d.1674716617.git.christophe.leroy@csgroup.eu Fixes: 41b7a34 ("powerpc: Book3S 64-bit outline-only KASAN support") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reported-by: Nathan Lynch <nathanl@linux.ibm.com> Suggested-by: Michael Ellerman <mpe@ellerman.id.au> Cc: Alexander Potapenko <glider@google.com> Cc: Andrey Konovalov <andreyknvl@gmail.com> Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: <stable@vger.kernel.org> [5.19+] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

When e.g. 8 bytes are to be read, sgm->consumed equals 8 immediately after sg_miter_next() call. The driver then increments it as bytes are read, so sgm->consumed becomes 16 and this warning triggers in sg_miter_stop(): WARN_ON(miter->consumed > miter->length); WARNING: CPU: 0 PID: 28 at lib/scatterlist.c:925 sg_miter_stop+0x2c/0x10c CPU: 0 PID: 28 Comm: kworker/0:2 Tainted: G W 6.9.0-rc5-dirty torvalds#249 Hardware name: Generic DT based system Workqueue: events_freezable mmc_rescan Call trace:. unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x44/0x5c dump_stack_lvl from __warn+0x78/0x16c __warn from warn_slowpath_fmt+0xb0/0x160 warn_slowpath_fmt from sg_miter_stop+0x2c/0x10c sg_miter_stop from moxart_request+0xb0/0x468 moxart_request from mmc_start_request+0x94/0xa8 mmc_start_request from mmc_wait_for_req+0x60/0xa8 mmc_wait_for_req from mmc_app_send_scr+0xf8/0x150 mmc_app_send_scr from mmc_sd_setup_card+0x1c/0x420 mmc_sd_setup_card from mmc_sd_init_card+0x12c/0x4dc mmc_sd_init_card from mmc_attach_sd+0xf0/0x16c mmc_attach_sd from mmc_rescan+0x1e0/0x298 mmc_rescan from process_scheduled_works+0x2e4/0x4ec process_scheduled_works from worker_thread+0x1ec/0x24c worker_thread from kthread+0xd4/0xe0 kthread from ret_from_fork+0x14/0x38 This patch adds initial zeroing of sgm->consumed. It is then incremented as bytes are read or written. Signed-off-by: Sergei Antonov <saproj@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Fixes: 3ee0e7c ("mmc: moxart-mmc: Use sg_miter for PIO") Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240422153607.963672-1-saproj@gmail.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

A malicious device can change its MSIX table size between the table ioremap() and subsequent accesses, resulting in a page fault: > BUG: unable to handle page fault for address: ffffc9000005a00c > #PF: supervisor write access in kernel mode > #PF: error_code(0x0002) - not-present page > PGD 5800067 P4D 5800067 PUD 645c067 PMD 645d067 PTE 0 > Oops: 0002 [#1] PREEMPT SMP KASAN > CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.17.0-rc1-00148-g16fc64ddb0ef-dirty torvalds#249 > RIP: 0010:__pci_write_msi_msg+0x3d9/0x3f0 > Call Trace: > <TASK> > pci_msi_domain_write_msg+0x61/0x70 > msi_domain_activate+0xe0/0x110 > __irq_domain_activate_irq+0x87/0xc0 > irq_domain_activate_irq+0x69/0x90 > __msi_domain_alloc_irqs+0x31a/0x5e0 > msi_domain_alloc_irqs_descs_locked+0x7b/0x110 > pci_msi_setup_msi_irqs+0x55/0x70 > __pci_enable_msix_range+0x57a/0x78f > pci_alloc_irq_vectors_affinity.cold+0x1a/0x2e > vp_find_vqs_msix+0x17e/0x790 > vp_find_vqs+0x3e/0x270 > virtnet_find_vqs+0x2b4/0x560 > virtnet_probe+0x734/0x1030 > virtio_dev_probe+0x25c/0x3c0 > really_probe+0x37d/0x660 > __driver_probe_device+0x19e/0x230 > driver_probe_device+0x4e/0xf0 > __driver_attach+0xfe/0x270 > bus_for_each_dev+0xff/0x150 > driver_attach+0x2d/0x40 > bus_add_driver+0x242/0x300 > driver_register+0x119/0x1a0 > register_virtio_driver+0x41/0x70 > virtio_net_driver_init+0x74/0x9b > do_one_initcall+0xcc/0x400 > kernel_init_freeable+0x3db/0x468 > kernel_init+0x1e/0x150 > ret_from_fork+0x22/0x30 > </TASK> To avoid this, cache the table size observed at the moment of table ioremap() and use the cache value. This, however, does not help drivers that peek at the PCIE_MSIX_FLAGS register directly. Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>

microcai and others added 3 commits January 9, 2015 12:45

[vt] fix 255 glyph limit, prepare for CJK font support

c7bfa14

[vt] diable setfont if we have cjk font in kernel

5a8d700

[vt] add cjk font that has 65536 chars

18e073a

darcyg closed this Jan 18, 2016

laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017

Merge pull request torvalds#249 from libos-nuse/merge-linux-4.8

4b77c32

Merge linux 4.8

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

3.18 utf8 #249

3.18 utf8 #249

darcyg commented Jan 18, 2016

3.18 utf8 #249

3.18 utf8 #249

Conversation

darcyg commented Jan 18, 2016