NULL pointer dereference in net/core/rtnetlink.c

[nathanchance]

See the upstream thread for the full context: https://lore.kernel.org/r/Yg2h2Q2vXFkkLGTh@dev-arch.archlinux-ax161/

[nickdesaulniers]

Should we consider lld commit 55c14d6dbfd8e7b86c15d2613fea3490078e2ae4 a regression?

cc @MaskRay

[nathanchance]

Should we consider lld commit 55c14d6dbfd8e7b86c15d2613fea3490078e2ae4 a regression?

Given that it actually resolves the reported issue, probably not but I am not sure. The more likely explanation is that llvm/llvm-project@55c14d6 just happened to fix an existing bug in LLD's code?

[nickdesaulniers]

ah, I misread the report, which was reported against lld-13 (for ppc64le).

I noticed that the 13.0.1 milestone still has open issues, but is closed (pretty sure the deadline for 13.0.1 already passed).
https://github.com/llvm/llvm-project/milestone/2

maybe the best we can do is require lld-14+ for ppc64le :(

[nathanchance]

Yes, LLVM 13.0.1 has been released already: https://github.com/llvm/llvm-project/releases/tag/llvmorg-13.0.1

I have not tried to look at the section header differences yet but that might give us a clue as to what went wrong.

I agree that this is probably a bug that is worth breaking the build over; we could stick a check and message in ld-version.sh like the one for ld.gold?

[MaskRay]

[ELF] Simplify DynamicSection content computation. NFC has NFC because to the best of my knowledge it did not change output. (Also, I tend to test a bunch of internal targets in various build modes to ensure correctness). If it accidentally fixed an issue, you may compare the output with llvm-readelf -d. There should be some differences.

[nathanchance]

It looks like the number of relocations is different?

$ llvm-readelf -d cbl-1594-bad/vmlinux
Dynamic section at offset 0x21bf4e0 contains 15 entries:
  Tag                Type        Name/Value
  0x000000000000001e (FLAGS)     TEXTREL
  0x000000006ffffffb (FLAGS_1)   PIE
  0x0000000000000015 (DEBUG)     0x0
  0x0000000000000007 (RELA)      0xc0000000021af620
  0x0000000000000008 (RELASZ)    3943056 (bytes)
  0x0000000000000009 (RELAENT)   24 (bytes)
  0x000000006ffffff9 (RELACOUNT) 164268
  0x0000000000000006 (SYMTAB)    0xc0000000021af438
  0x000000000000000b (SYMENT)    24 (bytes)
  0x0000000000000005 (STRTAB)    0xc0000000021af4b0
  0x000000000000000a (STRSZ)     48 (bytes)
  0x0000000000000016 (TEXTREL)   0x0
  0x000000006ffffef5 (GNU_HASH)  0xc0000000021af600
  0x0000000000000004 (HASH)      0xc0000000021af5d0
  0x0000000000000000 (NULL)      0x0

$ llvm-readelf -d cbl-1594-good/vmlinux
Dynamic section at offset 0x21bf4e0 contains 15 entries:
  Tag                Type        Name/Value
  0x000000000000001e (FLAGS)     TEXTREL
  0x000000006ffffffb (FLAGS_1)   PIE
  0x0000000000000015 (DEBUG)     0x0
  0x0000000000000007 (RELA)      0xc0000000021af620
  0x0000000000000008 (RELASZ)    3943056 (bytes)
  0x0000000000000009 (RELAENT)   24 (bytes)
  0x000000006ffffff9 (RELACOUNT) 164290
  0x0000000000000006 (SYMTAB)    0xc0000000021af438
  0x000000000000000b (SYMENT)    24 (bytes)
  0x0000000000000005 (STRTAB)    0xc0000000021af4b0
  0x000000000000000a (STRSZ)     48 (bytes)
  0x0000000000000016 (TEXTREL)   0x0
  0x000000006ffffef5 (GNU_HASH)  0xc0000000021af600
  0x0000000000000004 (HASH)      0xc0000000021af5d0
  0x0000000000000000 (NULL)      0x0

while makes sense because if I disable CONFIG_RELOCATABLE in the configuration that initially reproduced the issue, I do not see the NULL pointer dereference. I wonder if this is symptomatic of the RELACOUNT problem that was mentioned in #1581?

[MaskRay]

Likely related to DT_RELACOUNT in #1581. ld.lld reported DT_RELACOUNT may be fewer than the number of R_PPC64_RELATIVE relocations if there are position-independent long branch thunks. I think the kernel should work with the imprecise DT_RELACOUNT.

[nathanchance]

Commit d79976918852 ("powerpc/64: Add UADDR64 relocation support"), which fixed #1581, also resolves this issue. I have started a thread about whether or not that change is suitable for stable: https://lore.kernel.org/Yl8pNxSGUgeHZ1FT@dev-arch.thelio-3990X/