MIPI DSI Touchscreen support (waveshare 800x480) #1

provalinf · 2021-04-05T14:31:44Z

Hi,
I have a screen like this https://www.waveshare.com/wiki/4.3inch_DSI_LCD
That I can't get to work with the tinker board 2 (black screen).

linaro@linaro-alip:~$ dmesg | grep ili9
[    2.041912] tinker-mcu: tinker_mcu_ili9881c_probe: address = 0x36
[    2.048018] tinker-mcu: tinker_mcu_ili9881c_probe: i2c_id= 0x8
[    2.099652] tinker-mcu: tinker_mcu_ili9881c_probe: init_cmd_check[-6] failed, 0

linaro@linaro-alip:~$ dmesg | grep 5406
[    6.125932] tinker-ft5406: tinker_ft5406_probe: address = 0x38
[    6.131786] tinker-ft5406: tinker_ft5406_probe: touch is on DSI-0
[    6.647442] tinker-ft5406: tinker_ft5406_probe: wait connected timeout

If you have a solution to this, I'm interested.
Thank you!

The text was updated successfully, but these errors were encountered:

This patch fixes the following panic when use uvc function and do reboot during uvc preview. Unable to handle kernel NULL pointer dereference at virtual address 000001fd pgd = 85dd55c1 [000001fd] *pgd=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: galcore(O) CPU: 0 PID: 716 Comm: xc:RkAiqCoreThr Tainted: G W O 4.19.111 #18 Hardware name: Generic DT based system PC is at usb_gadget_deactivate+0x0/0x6c LR is at usb_function_deactivate+0x54/0x74 It's because that do reboot operation will call configfs_composite_unbind() to set cdev->gadget to NULL. Change-Id: I6fbfe9b58f865113d04ca7ce0b74b00f8d89227c Signed-off-by: William Wu <[email protected]>

This patch fixes the following panic when close the uvc application in usb host. Unable to handle kernel NULL pointer dereference at virtual address 00000003 pgd = 21faf91f [00000003] *pgd=151af835, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM Modules linked in: galcore(O) CPU: 1 PID: 720 Comm: uvc_gadget_pthr Tainted: G W O 4.19.111 #8 Hardware name: Generic DT based system PC is at uvcg_video_ep_queue+0x40/0x58 LR is at uvcg_video_ep_queue+0x38/0x58 ... [<b04fff54>] (uvcg_video_ep_queue) from [<b05003a4>] (uvcg_video_pump+0x7c/0x104) [<b05003a4>] (uvcg_video_pump) from [<b0527cd8>] (__video_do_ioctl+0x1c8/0x3a0) [<b0527cd8>] (__video_do_ioctl) from [<b052b40c>] (video_usercopy+0x200/0x494) [<b052b40c>] (video_usercopy) from [<b022043c>] (do_vfs_ioctl+0xac/0x798) [<b022043c>] (do_vfs_ioctl) from [<b0220b5c>] (ksys_ioctl+0x34/0x58) [<b0220b5c>] (ksys_ioctl) from [<b0101000>] (ret_fast_syscall+0x0/0x4c) Change-Id: I893e4c2b95f9b583423e68d68e7beff1cd114687 Signed-off-by: William Wu <[email protected]>

This enables the Contiguous Memory Allocator which allows drivers to allocate big physically-contiguous blocks of memory for use with hardware components that do not support I/O map nor scatter-gather. You can disable CMA by specifying "cma=0" on the kernel's command line. The original report issue: The coherent_pool>=5m will cause the kernel NULL pointer as below: Unable to handle kernel NULL pointer dereference at virtual address 00000018 pgd = ffffff80092c9000 [00000018] *pgd=00000000f7ffe003, *pud=00000000f7ffe003, *pmd=0000000000000000 Internal error: Oops: 96000005 [#1] SMP Modules linked in: CPU: 4 PID: 1 Comm: swapper/0 Tainted: G W 4.4.194 #185 Hardware name: Rockchip RK3399pro evb v14 board for linux (DT) task: ffffffc0f2c00000 task.stack: ffffffc00a36c000 PC is at addr_in_gen_pool+0x8/0x4c LR is at arch_in_atomic_pool+0x30/0x3c .. Signed-off-by: Caesar Wang <[email protected]> Change-Id: I2751ee2553726eef4695f2f70b3404ff7da0f4dd

Can not pass NULL address for vcodec_iommu_map_iommu, which will do access to the iova and size. Test on RK3399 EVB: [ 0.918046] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 0.919653] pgd = ffffff80095b2000 [ 0.919958] [00000000] *pgd=00000000f7ffe003, *pud=00000000f7ffe003, *pmd=0000000000000000 [ 0.920722] Internal error: Oops: 96000045 [#1] PREEMPT SMP [ 0.921220] Modules linked in: [ 0.921509] CPU: 4 PID: 1 Comm: swapper/0 Not tainted 4.4.194 #8 [ 0.922041] Hardware name: rockchip,rk3399-excavator-edp (DT) [ 0.922551] task: ffffffc00a368000 task.stack: ffffffc00a344000 [ 0.923080] PC is at ion_map_iommu+0x160/0x2c4 [ 0.923478] LR is at ion_map_iommu+0x148/0x2c4 Change-Id: I74837f7f7af2b62915af70ecf0be2f621484284f Signed-off-by: Jianqun Xu <[email protected]>

Fix system crash casued by failed to allocated ion heap. On RK3399 EVB: [ 0.924159] Unable to handle kernel NULL pointer dereference at virtual address 00000021 [ 0.928269] pgd = ffffff80095b2000 [ 0.928574] [00000021] *pgd=00000000f7ffe003, *pud=00000000f7ffe003, *pmd=0000000000000000 [ 0.929338] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 0.929836] Modules linked in: [ 0.930124] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.4.194 #7 [ 0.930656] Hardware name: rockchip,rk3399-excavator-edp (DT) [ 0.931166] task: ffffffc00a368000 task.stack: ffffffc00a344000 [ 0.931696] PC is at ion_handle_validate+0x28/0x6c [ 0.932128] LR is at ion_map_iommu+0x48/0x2c4 [ 0.932512] pc : [<ffffff8008811e0c>] lr : [<ffffff8008811fec>] pstate: 80400045 Change-Id: Iff428a745633e2b0188ebe8053baccecc7cdece5 Signed-off-by: Jianqun Xu <[email protected]>

rfkill_rk_probe will fail in some situation after calling wake_lock_init, but in failed situation, wake_lock_destroy is not called, it will cause system crash if userspace program read /sys/kernel/debug/wakeup_sources. Unable to handle kernel NULL pointer dereference at virtual address 00000010 [ 36.171834] pgd = ffffffc0dd710000 [ 36.175230] [00000010] *pgd=00000000dd480003, *pud=00000000dd480003, *pmd=0000000000000000 [ 36.183554] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 36.189129] Modules linked in: [ 36.192203] CPU: 4 PID: 738 Comm: Binder:605_4 Not tainted 4.4.126 #1 [ 36.198633] Hardware name: Rockchip RK3399 Excavator Board dp(Android) (DT) [ 36.205583] task: ffffffc0cb43de80 task.stack: ffffffc0cac4c000 [ 36.211502] PC is at _raw_spin_lock_irqsave+0x1c/0x50 [ 36.216553] LR is at print_wakeup_source_stats+0x30/0xf0 [ 36.221862] pc : [<ffffff8008b65890>] lr : [<ffffff800853e074>] pstate: a04001c5 [ 36.229242] sp : ffffffc0cac4fc50 [ 36.232554] x29: ffffffc0cac4fc70 x28: ffffffc0cac6ee80 [ 36.237901] x27: ffffffc0ed446f00 x26: ffffffc0cac4fd78 [ 36.243283] x25: ffffffc0cac4feb0 x24: ffffffc0cac6ee40 [ 36.248634] x23: 0000000000000000 x22: 0000000000000010 [ 36.253978] x21: ffffffc0cb43de80 x20: ffffff8009236db8 [ 36.259323] x19: fffffffffffffff8 x18: ffffffc0caf18000 [ 36.264675] x17: 00000070b84c8674 x16: ffffff80081c0e50 [ 36.270020] x15: 0000000000000000 x14: 0000000000000000 [ 36.275358] x13: 000000000000000a x12: 0000000000000020 [ 36.280705] x11: 00000000fffffffb x10: ffffffc0caf17673 [ 36.286051] x9 : 0000000005f5e0ff x8 : 0000000005f5e100 [ 36.291378] x7 : 0000000000012054 x6 : ffffffc0caf17675 [ 36.296711] x5 : 00000000ffffffff x4 : ffffff8008f98e4f [ 36.302054] x3 : 0000000000000140 x2 : ffffffc0cb43de80 [ 36.307398] x1 : 0000000000000001 x0 : 0000000000000010 Call trace: [ 37.884693] [<ffffff8008b65890>] _raw_spin_lock_irqsave+0x1c/0x50 [ 37.890778] [<ffffff800853e1ec>] wakeup_sources_stats_show+0xb8/0xc4 [ 37.897125] [<ffffff80081e2118>] seq_read+0x120/0x404 [ 37.902171] [<ffffff80081bfbc8>] __vfs_read+0x38/0xf4 [ 37.907215] [<ffffff80081c03d4>] vfs_read+0x78/0x12c [ 37.912175] [<ffffff80081c0eac>] SyS_read+0x5c/0xbc [ 37.917055] [<ffffff80080832f0>] el0_svc_naked+0x24/0x28 Signed-off-by: Wenping Zhang <[email protected]> Change-Id: I57216b16ffdd35bbcf0fda56924bf00a71d152ac

asusiot · 2021-09-09T09:30:01Z

hello @provalinf ,
this panel is not on the official qualified vendor list, but we can do basic checkings. can you send us 1. a pic of your board connected to the panel with the fpc cable 2. complete logs?

In line 800 (#1), nfp_cpp_area_alloc() allocates and initializes a CPP area structure. But in line 807 (#2), when the cache is allocated failed, this CPP area structure is not freed, which will result in memory leak. We can fix it by freeing the CPP area when the cache is allocated failed (#2). 792 int nfp_cpp_area_cache_add(struct nfp_cpp *cpp, size_t size) 793 { 794 struct nfp_cpp_area_cache *cache; 795 struct nfp_cpp_area *area; 800 area = nfp_cpp_area_alloc(cpp, NFP_CPP_ID(7, NFP_CPP_ACTION_RW, 0), 801 0, size); // #1: allocates and initializes 802 if (!area) 803 return -ENOMEM; 805 cache = kzalloc(sizeof(*cache), GFP_KERNEL); 806 if (!cache) 807 return -ENOMEM; // #2: missing free 817 return 0; 818 } Fixes: 4cb584e ("nfp: add CPP access core") Signed-off-by: Jianglei Nie <[email protected]> Acked-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Change-Id: Icfc7a09bdc2ab8733badf26d06b72a532f322fa7

Currently, with an unknown recv_type, mwifiex_usb_recv just return -1 without restoring the skb. Next time mwifiex_usb_rx_complete is invoked with the same skb, calling skb_put causes skb_over_panic. The bug is triggerable with a compromised/malfunctioning usb device. After applying the patch, skb_over_panic no longer shows up with the same input. Attached is the panic report from fuzzing. skbuff: skb_over_panic: text:000000003bf1b5fa len:2048 put:4 head:00000000dd6a115b data:000000000a9445d8 tail:0x844 end:0x840 dev:<NULL> kernel BUG at net/core/skbuff.c:109! invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 PID: 198 Comm: in:imklog Not tainted 5.6.0 #60 RIP: 0010:skb_panic+0x15f/0x161 Call Trace: <IRQ> ? mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] skb_put.cold+0x24/0x24 mwifiex_usb_rx_complete+0x26b/0xfcd [mwifiex_usb] __usb_hcd_giveback_urb+0x1e4/0x380 usb_giveback_urb_bh+0x241/0x4f0 ? __hrtimer_run_queues+0x316/0x740 ? __usb_hcd_giveback_urb+0x380/0x380 tasklet_action_common.isra.0+0x135/0x330 __do_softirq+0x18c/0x634 irq_exit+0x114/0x140 smp_apic_timer_interrupt+0xde/0x380 apic_timer_interrupt+0xf/0x20 </IRQ> Reported-by: Brendan Dolan-Gavitt <[email protected]> Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Change-Id: I08ae7777de5532155b763dbf632e64eb3cae0c47

In prealloc_elems_and_freelist(), the multiplication to calculate the size passed to bpf_map_area_alloc() could lead to an integer overflow. As a result, out-of-bounds write could occur in pcpu_freelist_populate() as reported by KASAN: [...] [ 16.968613] BUG: KASAN: slab-out-of-bounds in pcpu_freelist_populate+0xd9/0x100 [ 16.969408] Write of size 8 at addr ffff888104fc6ea0 by task crash/78 [ 16.970038] [ 16.970195] CPU: 0 PID: 78 Comm: crash Not tainted 5.15.0-rc2+ #1 [ 16.970878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 16.972026] Call Trace: [ 16.972306] dump_stack_lvl+0x34/0x44 [ 16.972687] print_address_description.constprop.0+0x21/0x140 [ 16.973297] ? pcpu_freelist_populate+0xd9/0x100 [ 16.973777] ? pcpu_freelist_populate+0xd9/0x100 [ 16.974257] kasan_report.cold+0x7f/0x11b [ 16.974681] ? pcpu_freelist_populate+0xd9/0x100 [ 16.975190] pcpu_freelist_populate+0xd9/0x100 [ 16.975669] stack_map_alloc+0x209/0x2a0 [ 16.976106] __sys_bpf+0xd83/0x2ce0 [...] The possibility of this overflow was originally discussed in [0], but was overlooked. Fix the integer overflow by changing elem_size to u64 from u32. [0] https://lore.kernel.org/bpf/[email protected]/ Fixes: 557c0c6 ("bpf: convert stackmap to pre-allocation") Signed-off-by: Tatsuhiko Yasumatsu <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Change-Id: I7b83fee36db912639b6c371630d0ebbed7f1c17c

Syzkaller report this: pf: pf version 1.04, major 47, cluster 64, nice 0 pf: No ATAPI disk detected kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 9887 Comm: syz-executor.0 Tainted: G C 5.1.0-rc3+ #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 RIP: 0010:pf_init+0x7af/0x1000 [pf] Code: 46 77 d2 48 89 d8 48 c1 e8 03 80 3c 28 00 74 08 48 89 df e8 03 25 a6 d2 4c 8b 23 49 8d bc 24 80 05 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 74 05 e8 e6 24 a6 d2 49 8b bc 24 80 05 00 00 e8 79 34 RSP: 0018:ffff8881abcbf998 EFLAGS: 00010202 RAX: 00000000000000b0 RBX: ffffffffc1e4a8a8 RCX: ffffffffaec50788 RDX: 0000000000039b10 RSI: ffffc9000153c000 RDI: 0000000000000580 RBP: dffffc0000000000 R08: ffffed103ee44e59 R09: ffffed103ee44e59 R10: 0000000000000001 R11: ffffed103ee44e58 R12: 0000000000000000 R13: ffffffffc1e4b028 R14: 0000000000000000 R15: 0000000000000020 FS: 00007f1b78a91700(0000) GS:ffff8881f7200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6d72b207f8 CR3: 00000001d5790004 CR4: 00000000007606f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? 0xffffffffc1e50000 do_one_initcall+0xbc/0x47d init/main.c:901 do_init_module+0x1b5/0x547 kernel/module.c:3456 load_module+0x6405/0x8c10 kernel/module.c:3804 __do_sys_finit_module+0x162/0x190 kernel/module.c:3898 do_syscall_64+0x9f/0x450 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x462e99 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f1b78a90c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000462e99 RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003 RBP: 00007f1b78a90c70 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f1b78a916bc R13: 00000000004bcefa R14: 00000000006f6fb0 R15: 0000000000000004 Modules linked in: pf(+) paride gpio_tps65218 tps65218 i2c_cht_wc ati_remote dc395x act_meta_skbtcindex act_ife ife ecdh_generic rc_xbox_dvd sky81452_regulator v4l2_fwnode leds_blinkm snd_usb_hiface comedi(C) aes_ti slhc cfi_cmdset_0020 mtd cfi_util sx8654 mdio_gpio of_mdio fixed_phy mdio_bitbang libphy alcor_pci matrix_keymap hid_uclogic usbhid scsi_transport_fc videobuf2_v4l2 videobuf2_dma_sg snd_soc_pcm179x_spi snd_soc_pcm179x_codec i2c_demux_pinctrl mdev snd_indigodj isl6405 mii enc28j60 cmac adt7316_i2c(C) adt7316(C) fmc_trivial fmc nf_reject_ipv4 authenc rc_dtt200u rtc_ds1672 dvb_usb_dibusb_mc dvb_usb_dibusb_mc_common dib3000mc dibx000_common dvb_usb_dibusb_common dvb_usb dvb_core videobuf2_common videobuf2_vmalloc videobuf2_memops regulator_haptic adf7242 mac802154 ieee802154 s5h1409 da9034_ts snd_intel8x0m wmi cx24120 usbcore sdhci_cadence sdhci_pltfm sdhci mmc_core joydev i2c_algo_bit scsi_transport_iscsi iscsi_boot_sysfs ves1820 lockd grace nfs_acl auth_rpcgss sunrp c ip_vs snd_soc_adau7002 snd_cs4281 snd_rawmidi gameport snd_opl3_lib snd_seq_device snd_hwdep snd_ac97_codec ad7418 hid_primax hid snd_soc_cs4265 snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer ac97_bus snd_compress snd soundcore ti_adc108s102 eeprom_93cx6 i2c_algo_pca mlxreg_hotplug st_pressure st_sensors industrialio_triggered_buffer kfifo_buf industrialio v4l2_common videodev media snd_soc_adau_utils rc_pinnacle_grey rc_core pps_gpio leds_lm3692x nandcore ledtrig_pattern iptable_security iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bpfilter ip6_vti ip_vti ip_gre ipip sit tunnel4 ip_tunnel hsr veth netdevsim vxcan batman_adv cfg80211 rfkill chnl_net caif nlmon dummy team bonding vcan bridge stp llc ip6_gre gre ip6_tunnel tunnel6 tun mousedev ppdev tpm kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ide_pci_generic aes_x86_64 piix crypto_simd input_leds psmouse cryp td glue_helper ide_core intel_agp serio_raw intel_gtt agpgart ata_generic i2c_piix4 pata_acpi parport_pc parport rtc_cmos floppy sch_fq_codel ip_tables x_tables sha1_ssse3 sha1_generic ipv6 [last unloaded: paride] Dumping ftrace buffer: (ftrace buffer empty) Change-Id: I8981e925da48b9df784f60dfe5a407ce6837f7a5 ---[ end trace 7a818cf5f210d79e ]--- If alloc_disk fails in pf_init_units, pf->disk will be NULL, however in pf_detect and pf_exit, it's not check this before free.It may result a NULL pointer dereference. Also when register_blkdev failed, blk_cleanup_queue() and blk_mq_free_tag_set() should be called to free resources. Reported-by: Hulk Robot <[email protected]> Fixes: 6ce59025f118 ("paride/pf: cleanup queues when detection fails") Signed-off-by: YueHaibing <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Change-Id: Id52b3f38a58d8b080a6c3c57ee602fc9614a81d8

commit 37cb28ec7d3a36a5bace7063a3dba633ab110f8b upstream. The conditional branch instructions on MIPS use 18-bit signed offsets allowing for a branch range of 128 KBytes (backward and forward). However, this limit is not observed by the cBPF JIT compiler, and so the JIT compiler emits out-of-range branches when translating certain cBPF programs. A specific example of such a cBPF program is included in the "BPF_MAXINSNS: exec all MSH" test from lib/test_bpf.c that executes anomalous machine code containing incorrect branch offsets under JIT. Furthermore, this issue can be abused to craft undesirable machine code, where the control flow is hijacked to execute arbitrary Kernel code. The following steps can be used to reproduce the issue: # echo 1 > /proc/sys/net/core/bpf_jit_enable # modprobe test_bpf test_name="BPF_MAXINSNS: exec all MSH" This should produce multiple warnings from build_bimm() similar to: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 209 at arch/mips/mm/uasm-mips.c:210 build_insn+0x558/0x590 Micro-assembler field overflow Modules linked in: test_bpf(+) CPU: 0 PID: 209 Comm: modprobe Not tainted 5.14.3 #1 Stack : 00000000 807bb824 82b33c9c 801843c0 00000000 00000004 00000000 63c9b5ee 82b33af4 80999898 80910000 80900000 82fd6030 00000001 82b33a98 82087180 00000000 00000000 80873b28 00000000 000000fc 82b3394c 00000000 2e34312e 6d6d6f43 809a180f 809a1836 6f6d203a 80900000 00000001 82b33bac 80900000 00027f80 00000000 00000000 807bb824 00000000 804ed790 001cc317 00000001 [...] Call Trace: [<80108f44>] show_stack+0x38/0x118 [<807a7aac>] dump_stack_lvl+0x5c/0x7c [<807a4b3c>] __warn+0xcc/0x140 [<807a4c3c>] warn_slowpath_fmt+0x8c/0xb8 [<8011e198>] build_insn+0x558/0x590 [<8011e358>] uasm_i_bne+0x20/0x2c [<80127b48>] build_body+0xa58/0x2a94 [<80129c98>] bpf_jit_compile+0x114/0x1e4 [<80613fc4>] bpf_prepare_filter+0x2ec/0x4e4 [<8061423c>] bpf_prog_create+0x80/0xc4 [<c0a006e4>] test_bpf_init+0x300/0xba8 [test_bpf] [<8010051c>] do_one_initcall+0x50/0x1d4 [<801c5e54>] do_init_module+0x60/0x220 [<801c8b20>] sys_finit_module+0xc4/0xfc [<801144d0>] syscall_common+0x34/0x58 [...] ---[ end trace a287d9742503c645 ]--- Then the anomalous machine code executes: => 0xc0a18000: addiu sp,sp,-16 0xc0a18004: sw s3,0(sp) 0xc0a18008: sw s4,4(sp) 0xc0a1800c: sw s5,8(sp) 0xc0a18010: sw ra,12(sp) 0xc0a18014: move s5,a0 0xc0a18018: move s4,zero 0xc0a1801c: move s3,zero # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0) 0xc0a18020: lui t6,0x8012 0xc0a18024: ori t4,t6,0x9e14 0xc0a18028: li a1,0 0xc0a1802c: jalr t4 0xc0a18030: move a0,s5 0xc0a18034: bnez v0,0xc0a1ffb8 # incorrect branch offset 0xc0a18038: move v0,zero 0xc0a1803c: andi s4,s3,0xf 0xc0a18040: b 0xc0a18048 0xc0a18044: sll s4,s4,0x2 [...] # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0) 0xc0a1ffa0: lui t6,0x8012 0xc0a1ffa4: ori t4,t6,0x9e14 0xc0a1ffa8: li a1,0 0xc0a1ffac: jalr t4 0xc0a1ffb0: move a0,s5 0xc0a1ffb4: bnez v0,0xc0a1ffb8 # incorrect branch offset 0xc0a1ffb8: move v0,zero 0xc0a1ffbc: andi s4,s3,0xf 0xc0a1ffc0: b 0xc0a1ffc8 0xc0a1ffc4: sll s4,s4,0x2 # __BPF_STMT(BPF_LDX | BPF_B | BPF_MSH, 0) 0xc0a1ffc8: lui t6,0x8012 0xc0a1ffcc: ori t4,t6,0x9e14 0xc0a1ffd0: li a1,0 0xc0a1ffd4: jalr t4 0xc0a1ffd8: move a0,s5 0xc0a1ffdc: bnez v0,0xc0a3ffb8 # correct branch offset 0xc0a1ffe0: move v0,zero 0xc0a1ffe4: andi s4,s3,0xf 0xc0a1ffe8: b 0xc0a1fff0 0xc0a1ffec: sll s4,s4,0x2 [...] # epilogue 0xc0a3ffb8: lw s3,0(sp) 0xc0a3ffbc: lw s4,4(sp) 0xc0a3ffc0: lw s5,8(sp) 0xc0a3ffc4: lw ra,12(sp) 0xc0a3ffc8: addiu sp,sp,16 0xc0a3ffcc: jr ra 0xc0a3ffd0: nop To mitigate this issue, we assert the branch ranges for each emit call that could generate an out-of-range branch. Fixes: 36366e367ee9 ("MIPS: BPF: Restore MIPS32 cBPF JIT") Fixes: c6610de ("MIPS: net: Add BPF JIT") Signed-off-by: Piotr Krysiuk <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: Johan Almbladh <[email protected]> Acked-by: Johan Almbladh <[email protected]> Cc: Paul Burton <[email protected]> Cc: Thomas Bogendoerfer <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Ovidiu Panait <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Change-Id: Ie6eb0168b097b4f9be243f205bdea8f085411e41

…_tcpsk() [ Upstream commit 587acad ] Coverity reports a possible NULL dereferencing problem: in smc_vlan_by_tcpsk(): 6. returned_null: netdev_lower_get_next returns NULL (checked 29 out of 30 times). 7. var_assigned: Assigning: ndev = NULL return value from netdev_lower_get_next. 1623 ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower); CID 1468509 (#1 of 1): Dereference null return value (NULL_RETURNS) 8. dereference: Dereferencing a pointer that might be NULL ndev when calling is_vlan_dev. 1624 if (is_vlan_dev(ndev)) { Remove the manual implementation and use netdev_walk_all_lower_dev() to iterate over the lower devices. While on it remove an obsolete function parameter comment. Fixes: cb9d43f ("net/smc: determine vlan_id of stacked net_device") Suggested-by: Julian Wiedmann <[email protected]> Signed-off-by: Karsten Graul <[email protected]> Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Change-Id: I13111ad44bebfbfd47c81ddc753aa41918ae40d8

…g clear_user() commit c1e63117711977cc4295b2ce73de29dd17066c82 upstream. To clear a user buffer we cannot simply use memset, we have to use clear_user(). With a virtio-mem device that registers a vmcore_cb and has some logically unplugged memory inside an added Linux memory block, I can easily trigger a BUG by copying the vmcore via "cp": systemd[1]: Starting Kdump Vmcore Save Service... kdump[420]: Kdump is using the default log level(3). kdump[453]: saving to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[458]: saving vmcore-dmesg.txt to /sysroot/var/crash/127.0.0.1-2021-11-11-14:59:22/ kdump[465]: saving vmcore-dmesg.txt complete kdump[467]: saving vmcore BUG: unable to handle page fault for address: 00007f2374e01000 #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation PGD 7a523067 P4D 7a523067 PUD 7a528067 PMD 7a525067 PTE 800000007048f867 Oops: 0003 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 468 Comm: cp Not tainted 5.15.0+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-27-g64f37cc530f1-prebuilt.qemu.org 04/01/2014 RIP: 0010:read_from_oldmem.part.0.cold+0x1d/0x86 Code: ff ff ff e8 05 ff fe ff e9 b9 e9 7f ff 48 89 de 48 c7 c7 38 3b 60 82 e8 f1 fe fe ff 83 fd 08 72 3c 49 8d 7d 08 4c 89 e9 89 e8 <49> c7 45 00 00 00 00 00 49 c7 44 05 f8 00 00 00 00 48 83 e7 f81 RSP: 0018:ffffc9000073be08 EFLAGS: 00010212 RAX: 0000000000001000 RBX: 00000000002fd000 RCX: 00007f2374e01000 RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00007f2374e01008 RBP: 0000000000001000 R08: 0000000000000000 R09: ffffc9000073bc50 R10: ffffc9000073bc48 R11: ffffffff829461a8 R12: 000000000000f000 R13: 00007f2374e01000 R14: 0000000000000000 R15: ffff88807bd421e8 FS: 00007f2374e12140(0000) GS:ffff88807f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2374e01000 CR3: 000000007a4aa000 CR4: 0000000000350eb0 Call Trace: read_vmcore+0x236/0x2c0 proc_reg_read+0x55/0xa0 vfs_read+0x95/0x190 ksys_read+0x4f/0xc0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Some x86-64 CPUs have a CPU feature called "Supervisor Mode Access Prevention (SMAP)", which is used to detect wrong access from the kernel to user buffers like this: SMAP triggers a permissions violation on wrong access. In the x86-64 variant of clear_user(), SMAP is properly handled via clac()+stac(). To fix, properly use clear_user() when we're dealing with a user buffer. Link: https://lkml.kernel.org/r/[email protected] Fixes: 997c136 ("fs/proc/vmcore.c: add hook to read_from_oldmem() to check for non-ram pages") Signed-off-by: David Hildenbrand <[email protected]> Acked-by: Baoquan He <[email protected]> Cc: Dave Young <[email protected]> Cc: Baoquan He <[email protected]> Cc: Vivek Goyal <[email protected]> Cc: Philipp Rudo <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: David Hildenbrand <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Change-Id: I1245214607c5134654a1676c36a28f391b3f1e5a

…c_wait [ Upstream commit b922f622592af76b57cbc566eaeccda0b31a3496 ] This bug report shows up when running our research tools. The reports is SOOB read, but it seems SOOB write is also possible a few lines below. In details, fw.len and sw.len are inputs coming from io. A len over the size of self->rpc triggers SOOB. The patch fixes the bugs by adding sanity checks. The bugs are triggerable with compromised/malfunctioning devices. They are potentially exploitable given they first leak up to 0xffff bytes and able to overwrite the region later. The patch is tested with QEMU emulater. This is NOT tested with a real device. Attached is the log we found by fuzzing. BUG: KASAN: slab-out-of-bounds in hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] Read of size 4 at addr ffff888016260b08 by task modprobe/213 CPU: 0 PID: 213 Comm: modprobe Not tainted 5.6.0 #1 Call Trace: dump_stack+0x76/0xa0 print_address_description.constprop.0+0x16/0x200 ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] __kasan_report.cold+0x37/0x7c ? aq_hw_read_reg_bit+0x60/0x70 [atlantic] ? hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] kasan_report+0xe/0x20 hw_atl_utils_fw_upload_dwords+0x393/0x3c0 [atlantic] hw_atl_utils_fw_rpc_call+0x95/0x130 [atlantic] hw_atl_utils_fw_rpc_wait+0x176/0x210 [atlantic] hw_atl_utils_mpi_create+0x229/0x2e0 [atlantic] ? hw_atl_utils_fw_rpc_wait+0x210/0x210 [atlantic] ? hw_atl_utils_initfw+0x9f/0x1c8 [atlantic] hw_atl_utils_initfw+0x12a/0x1c8 [atlantic] aq_nic_ndev_register+0x88/0x650 [atlantic] ? aq_nic_ndev_init+0x235/0x3c0 [atlantic] aq_pci_probe+0x731/0x9b0 [atlantic] ? aq_pci_func_init+0xc0/0xc0 [atlantic] local_pci_probe+0xd3/0x160 pci_device_probe+0x23f/0x3e0 Reported-by: Brendan Dolan-Gavitt <[email protected]> Signed-off-by: Zekun Shen <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]> Change-Id: I9696479ebaa080f0c39d19e7f4fc94bcee8a593c

p1r473 mentioned this issue Apr 21, 2021

Raspbian official 7" touchscreen doesnt work on the 2S #2

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MIPI DSI Touchscreen support (waveshare 800x480) #1

MIPI DSI Touchscreen support (waveshare 800x480) #1

provalinf commented Apr 5, 2021

asusiot commented Sep 9, 2021

MIPI DSI Touchscreen support (waveshare 800x480) #1

MIPI DSI Touchscreen support (waveshare 800x480) #1

Comments

provalinf commented Apr 5, 2021

asusiot commented Sep 9, 2021