Re: [PATCH v2] usb: typec: tcpm: Add NULL check before dereferencing config

[Douglas Gilbert]

On 2019-07-31 6:47 p.m., Douglas Gilbert wrote:
> On 2019-07-24 4:38 p.m., Guenter Roeck wrote:
> > When instantiating tcpm on an NXP OM 13588 board with NXP PTN5110,
> > the following crash is seen when writing into the 'preferred_role'
> > sysfs attribute.
> >
> > Unable to handle kernel NULL pointer dereference at virtual address 00000028
> > pgd = f69149ad
> > [00000028] *pgd=00000000
> > Internal error: Oops: 5 [#1] THUMB2
> > Modules linked in: tcpci tcpm
> > CPU: 0 PID: 1882 Comm: bash Not tainted 5.1.18-sama5-armv7-r2 #4
> > Hardware name: Atmel SAMA5
> > PC is at tcpm_try_role+0x3a/0x4c [tcpm]
> > LR is at tcpm_try_role+0x15/0x4c [tcpm]
> > pc : [<bf8000e2>]ÂÂÂ lr : [<bf8000bd>]ÂÂÂ psr: 60030033
> > sp : dc1a1e88 ip : c03fb47d fp : 00000000
> > r10: dc216190Â r9 : dc1a1f78Â r8 : 00000001
> > r7 : df4ae044Â r6 : dd032e90Â r5 : dd1ce340Â r4 : df4ae054
> > r3 : 00000000Â r2 : 00000000Â r1 : 00000000Â r0 : df4ae044
> > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none
> > Control: 50c53c7d Table: 3efec059 DAC: 00000051
> > Process bash (pid: 1882, stack limit = 0x6a6d4aa5)
> > Stack: (0xdc1a1e88 to 0xdc1a2000)
> > 1e80:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ dd05d808 dd1ce340 00000001 00000007 dd1ce340 c03fb4a7
> > 1ea0: 00000007 00000007 dc216180 00000000 00000000 c01e1e03 00000000 00000000
> > 1ec0: c0907008 dee98b40 c01e1d5d c06106c4 00000000 00000000 00000007 c0194e8b
> > 1ee0: 0000000a 00000400 00000000 c01a97db dc22bf00 ffffe000 df4b6a00 df745900
> > 1f00: 00000001 00000001 000000dd c01a9c2f 7aeab3be c0907008 00000000 dc22bf00
> > 1f20: c0907008 00000000 00000000 00000000 00000000 7aeab3be 00000007 dee98b40
> > 1f40: 005dc318 dc1a1f78 00000000 00000000 00000007 c01969f7 0000000a c01a20cb
> > 1f60: dee98b40 c0907008 dee98b40 005dc318 00000000 c0196b9b 00000000 00000000
> > 1f80: dee98b40 7aeab3be 00000074 005dc318 b6f3bdb0 00000004 c0101224 dc1a0000
> > 1fa0: 00000004 c0101001 00000074 005dc318 00000001 005dc318 00000007 00000000
> > 1fc0: 00000074 005dc318 b6f3bdb0 00000004 00000007 00000007 00000000 00000000
> > 1fe0: 00000004 be800880 b6ed35b3 b6e5c746 60030030 00000001 00000000 00000000
> > [<bf8000e2>] (tcpm_try_role [tcpm]) from [<c03fb4a7>] 
> > (preferred_role_store+0x2b/0x5c)
> > [<c03fb4a7>] (preferred_role_store) from [<c01e1e03>] 
> > (kernfs_fop_write+0xa7/0x150)
> > [<c01e1e03>] (kernfs_fop_write) from [<c0194e8b>] (__vfs_write+0x1f/0x104)
> > [<c0194e8b>] (__vfs_write) from [<c01969f7>] (vfs_write+0x6b/0x104)
> > [<c01969f7>] (vfs_write) from [<c0196b9b>] (ksys_write+0x43/0x94)
> > [<c0196b9b>] (ksys_write) from [<c0101001>] (ret_fast_syscall+0x1/0x62)
> >
> > Since commit 96232cbc6c994 ("usb: typec: tcpm: support get typec and pd
> > config from device properties"), the 'config' pointer in struct tcpc_dev
> > is optional when registering a Type-C port. Since it is optional, we have
> > to check if it is NULL before dereferencing it.
> >
> > Reported-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
> > Cc: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
> > Fixes: 96232cbc6c994 ("usb: typec: tcpm: support get typec and pd config from 
> > device properties")
> > Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
> > ---
> > v2: Added missing Cc:. Sorry for the noise.
> >
> > Doug:
> > ÂÂÂÂ I didn't add your Tested-by: since I added more code.
> > ÂÂÂÂ It would be great if you can re-test.
> >
> > Â drivers/usb/typec/tcpm/tcpm.c | 7 ++++---
> > Â 1 file changed, 4 insertions(+), 3 deletions(-)
>
> Tested-by: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>
>
>
> This time the Linux system is an Acme Systems Arietta which is a
> Atmel at91sam9g25 based board. Test was run with lk 5.1.19 .
> Without the patch I got the oops described above ("PC is at
> tcpm_try_role+0x40/0x74 [tcpm]") when writing into the 'preferred_role'
> sysfs attribute. With this patch it worked okay.

Today I tried this patch on lk 5.2.5 with the same hardware and it
worked, as expected.

Doug Gilbert

> Can't test the "out of protocol" PD Attention command oops because I
> don't have another OM13588 at the other end (of the USB-C cable) to
> send it. I may be able to solve that problem as well. The OM13588
> seems like a good attack vector ... and NXP continue to improve
> its software (I'm talking about when it runs with a KL27Z which is
> an Arduino clone). It can now read the current capability of an
> E-marked USB-C (M to M) cable. The only 5 Amp cable I have is
> the one that Apple sells (as an _extra_ (cheapskates) to their 87W
> USB-C power adapter (for MacBooks)).