Update exploit.md

Author: d4em0n

pocs/linux/kernelctf/CVE-2024-53141_lts/docs/exploit.md

@@ -11,39 +11,41 @@ static int
 bitmap_ip_uadt(struct ip_set *set, struct nlattr *tb[],
 	       enum ipset_adt adt, u32 *lineno, u32 flags, bool retried)
 {
+	if (ip < map->first_ip || ip > map->last_ip) // [1]
+		return -IPSET_ERR_BITMAP_RANGE;
         ...
 	if (tb[IPSET_ATTR_IP_TO]) {
 		ret = ip_set_get_hostipaddr4(tb[IPSET_ATTR_IP_TO], &ip_to);
 		if (ret)
 			return ret;
 		if (ip > ip_to) {
 			swap(ip, ip_to);
-			if (ip < map->first_ip) // [1]
+			if (ip < map->first_ip) // [2]
 				return -IPSET_ERR_BITMAP_RANGE;
 		}       
 	} else if (tb[IPSET_ATTR_CIDR]) {
 		u8 cidr = nla_get_u8(tb[IPSET_ATTR_CIDR]);
                 ...
-		ip_set_mask_from_to(ip, ip_to, cidr); // [2]
+		ip_set_mask_from_to(ip, ip_to, cidr); // [3]
 	} else {
 		ip_to = ip;
 	}
 
-	if (ip_to > map->last_ip) // [3]
+	if (ip_to > map->last_ip) // [4]
 		return -IPSET_ERR_BITMAP_RANGE;
 
-	for (; !before(ip_to, ip); ip += map->hosts) { // [4]
+	for (; !before(ip_to, ip); ip += map->hosts) { // [5]
 		e.id = ip_to_id(map, ip);
 		ret = adtfn(set, &e, &ext, &ext, flags);
 ```
 
-When `tb[IPSET_ATTR_IP_TO]` is not present but `tb[IPSET_ATTR_CIDR]` exists, `ip` and `ip_to` calculated via `ip_set_mask_from_to` based on `tb[IPSET_ATTR_CIDR]`. It's possible to have `ip` less than the actual `map->first_ip` and there's no check of `ip` after that. Therefore, the loop at [4] can proceed outside range ip that allocated (`map->first_ip` until `map->last_ip`).
+When `tb[IPSET_ATTR_IP_TO]` is not present but `tb[IPSET_ATTR_CIDR]` exists, `ip` and `ip_to` calculated via `ip_set_mask_from_to` based on `tb[IPSET_ATTR_CIDR]`. It's possible to have `ip` less than the actual `map->first_ip` and there's no check of `ip` after that.
 
+Consider when we have `map->first_ip` to be `0xffffffcb` and `map->last_ip` be `0xffffffff`, then we pass `IPSET_ATTR_IP` with value `0xffffffff` and `IPSET_ATTR_CIDR` with `3`, the result after [3] will make `ip` equal to `0xe0000000` and `ip_to` equal to `0xffffffff`, it would pass the check at [1], [4] and continue proceed to [5]. Therefore, the loop at [5] can proceed outside range ip that allocated (`map->first_ip` until `map->last_ip`).
 
 # Primitives
-## OOB Write to Kernel Heap Leak
 
-`adtfn` will resolve to `bitmap_ip_add` function (defined as `mtype_add` in `net/netfilter/ipset/ip_set_bitmap_gen.h`). It will fetch extension `x` from `map->extensions` with `e.id` as index.
+`adtfn` will resolve to `bitmap_ip_add` function (defined as `mtype_add` in `net/netfilter/ipset/ip_set_bitmap_gen.h`, mtype is just macro to `bitmap_ip`). It will fetch extension `x` from `map.extensions` with `e.id` as index.
 ```c
 #define get_ext(set, map, id)	((map)->extensions + ((set)->dsize * (id)))
 
@@ -57,14 +59,17 @@ mtype_add(struct ip_set *set, void *value, const struct ip_set_ext *ext,
 	int ret = mtype_do_add(e, map, flags, dsize: set->dsize);
 ```
 `e.id` comes from `ip_to_id` from previous function, if we craft such `id` it can lead to out-of-bounds later when that function perform on `x`.
+
 ```c
 static u32
 ip_to_id(const struct bitmap_ip *m, u32 ip)
 {
 	return ((ip & ip_set_hostmask(m->netmask)) - m->first_ip) / m->hosts;
 }
 ```
+We also can control the size of map (`bitmap_ip` type) by passing `first_ip` and `last_ip` when we initially create the ip set.
 
+## OOB Write to Kernel Heap Leak
 By crafting `e.id` it can lead OOB write, for example when we set the comment in sets, it can spill the kernel heap address in the next chunk because `comment` in `ip_set_init_comment` is outside the range. 
 ```c
 static int
@@ -87,7 +92,11 @@ ip_set_init_comment(struct ip_set *set, struct ip_set_comment *comment,
 	rcu_assign_pointer(comment->c, c);
 }
 ```
-This is the path that we used to leak kernel heap addr, by shaping heap to `..[skbuff][bitmap_ip][skbuff][skbuff]..` the OOB write of kernel addr will spilled to the next chunk which is socket buffer. By receiving socket buffer, it can contain kernel heap address so we can use it for the next step exploitation.
+This is the path that we used to leak kernel heap addr, by shaping heap to `..[skbuff][bitmap_ip][skbuff][skbuff]..` the OOB write of kernel addr will spilled to the next chunk which is socket buffer.
+
+In our exploit we choose to work on kmalloc-cg-1024 in this step, we allocate `bitmap_ip` and spray socket buffer at kmalloc-cg-1024. `ip_set_init_comment` will spilled kernel heap addr from kmalloc-192 to the socket buffer.
+
+By receiving socket buffer, we can get kernel heap address to use it for the next step exploitation.
 
 ## OOB Write Arbitrary Value
 Another type of OOB that we can use is OOB write with arbitrary value. This works using set that contain `counter`.
@@ -135,9 +144,10 @@ void free_msg(struct msg_msg *msg)
 	}
 }
 ```
-The victim object (`struct bitmap_ip`) is allocated with `GFP_KERNEL_ACCOUNT` so it's guarantee can reside in the same slab cache with `msg_msgseg` object. So we put `bitmap_ip` right before `msg_msgseg`, then perform OOB write so we can write arbitrary value on `msg_msgseg.next`.
 
-By using arbitrary free, we choose `pipe_buffer` as another victim object because it's familiar for us and easy to plan for the next step of exploit. But the kernel heap leak primitives we had only allocate buffer on generic kernel cache, so we kind of guess a little bit to get `pipe_buffer` address that located in account cache. Basically, from our observation we can calculate `leak_addr ~(0x10000000 - 1)` with `leak_addr` as kernel heap addr leaked from kmalloc-192 chunk, we can guess `pipe_buffer` in confident probability.
+In this step choose to work on kmalloc-cg-2048, we allocate `bitmap_ip` and spray `msg_msgseg` at kmalloc-cg-2048. The victim object (`struct bitmap_ip`) is allocated with `GFP_KERNEL_ACCOUNT` so it's guarantee can reside in the same slab cache with `msg_msgseg` object. So we put `bitmap_ip` right before `msg_msgseg`, then perform OOB write so we can write arbitrary value on `msg_msgseg.next`.
+
+By using arbitrary free, we choose `pipe_buffer` as another victim object because it's familiar for us and easy to plan for the next step of exploit. But the kernel heap leak primitives we had only allocate buffer on generic kernel cache (kmalloc-192), so we kind of guess a little bit to get `pipe_buffer` address that located in account cache. Basically, from our observation we can calculate `leak_addr ~(0x10000000 - 1)` with `leak_addr` as kernel heap addr leaked from kmalloc-192 chunk, we can guess `pipe_buffer` in confident probability.
 
 ## Use-After-Free to Control RIP
 In this step, we already free `pipe_buffer` by arbitrary free. Next, we reclaim victim `pipe_buffer` using socket buffer. We spray socket buffer and hope it placed at same address as `pipe_buffer`. Then, we write to the pipe and it will filled one of our socket buffer with `pipe_buffer` content.
@@ -148,7 +158,7 @@ Controlling RIP, we simply free the that socket buffer and reallocate with new o
 
 # Control RIP to ROP Chain
 We reached this code path where we control all fields in `pipe_buffer`.
-```
+```c
 static inline void pipe_buf_release(struct pipe_inode_info *pipe,
 				    struct pipe_buffer *buf)
 {