Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B. The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog. Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog.
Unified · Split
| @@ -1026,6 +1026,20 @@ static void replace_effective_prog(struct cgroup *cgrp, · 1025 unmodified lines | ||
| 1026 | 1026 | } |
| 1027 | 1027 | } |
| 1028 | 1028 | |
| 1029 | +static bool cgroup_bpf_storages_compatible(struct bpf_prog *old_prog, | |
| 1030 | + struct bpf_prog *new_prog) | |
| 1031 | +{ | |
| 1032 | + enum bpf_cgroup_storage_type stype; | |
| 1033 | + | |
| 1034 | + for_each_cgroup_storage_type(stype) { | |
| 1035 | + if (old_prog->aux->cgroup_storage[stype] != | |
| 1036 | + new_prog->aux->cgroup_storage[stype]) | |
| 1037 | + return false; | |
| 1038 | + } | |
| 1039 | + | |
| 1040 | + return true; | |
| 1041 | +} | |
| 1042 | + | |
| 1029 | 1043 | /** |
| 1030 | 1044 | * __cgroup_bpf_replace() - Replace link's program and propagate the change |
| 1031 | 1045 | * to descendants |
| @@ -1064,6 +1078,9 @@ static int __cgroup_bpf_replace(struct cgroup *cgrp, · 32 unmodified lines | ||
| 1064 | 1078 | if (!found) |
| 1065 | 1079 | return -ENOENT; |
| 1066 | 1080 | |
| 1081 | + if (!cgroup_bpf_storages_compatible(link->link.prog, new_prog)) | |
| 1082 | + return -EINVAL; | |
| 1083 | + | |
| 1067 | 1084 | cgrp->bpf.revisions[atype] += 1; |
| 1068 | 1085 | old_prog = xchg(&link->link.prog, new_prog); |
| 1069 | 1086 | replace_effective_prog(cgrp, atype, pl); |