DEBIAN-CVE-2024-43837

In the Linux kernel, the following vulnerability has been resolved: bpf: Fix null pointer dereference in resolveprogtype() for BPFPROGTYPEEXT When loading a EXT program without specifying attr->attach_prog_fd, the prog->aux->dst_prog will be null. At this time, calling resolveprogtype() anywhere will result in a null pointer dereference. Example stack trace: [ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 8.108262] Mem abort info: [ 8.108384] ESR = 0x0000000096000004 [ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits [ 8.108722] SET = 0, FnV = 0 [ 8.108827] EA = 0, S1PTW = 0 [ 8.108939] FSC = 0x04: level 0 translation fault [ 8.109102] Data abort info: [ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000 [ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000 [ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 8.112783] Modules linked in: [ 8.113120] CPU: 0 PID: 99 Comm: mayaccessdire Not tainted 6.10.0-rc3-next-20240613-dirty #1 [ 8.113230] Hardware name: linux,dummy-virt (DT) [ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 8.113429] pc : mayaccessdirectpktdata+0x24/0xa0 [ 8.113746] lr : addsubprogandkfunc+0x634/0x8e8 [ 8.113798] sp : ffff80008283b9f0 [ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001 [ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000 [ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000 [ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff [ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720 [ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720 [ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4 [ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f [ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c [ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000 [ 8.114126] Call trace: [ 8.114159] mayaccessdirectpktdata+0x24/0xa0 [ 8.114202] bpfcheck+0x3bc/0x28c0 [ 8.114214] bpfprogload+0x658/0xa58 [ 8.114227] _sysbpf+0xc50/0x2250 [ 8.114240] _arm64sysbpf+0x28/0x40 [ 8.114254] invokesyscall.constprop.0+0x54/0xf0 [ 8.114273] doel0svc+0x4c/0xd8 [ 8.114289] el0svc+0x3c/0x140 [ 8.114305] el0t64synchandler+0x134/0x150 [ 8.114331] el0t64sync+0x168/0x170 [ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403) [ 8.118672] ---[ end trace 0000000000000000 ]--- One way to fix it is by forcing attach_prog_fd non-empty when bpfprogload(). But this will lead to libbpf_probe_bpf_prog_type API broken which use verifier log to probe prog type and will log nothing if we reject invalid EXT prog before bpfcheck(). Another way is by adding null check in resolveprogtype(). The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve to prog->aux->dstprog->type only for BPFPROGTYPEEXT") which wanted to correct type resolution for BPFPROGTYPETRACING programs. Before that, the type resolution of BPFPROGTYPEEXT prog actually follows the logic below: prog->aux->dstprog ? prog->aux->dstprog->type : prog->type; It implies that when EXT program is not yet attached to dst_prog, the prog type should be EXT itself. This code worked fine in the past. So just keep using it. Fix this by returning prog->type for BPFPROGTYPEEXT if dst_prog is not present in resolveprog_type().