Add kernelCTF CVE-2024-45016_lts_cos_mitigation#261
Add kernelCTF CVE-2024-45016_lts_cos_mitigation#261hexfoureight wants to merge 15 commits intogoogle:masterfrom
Conversation
JordyZomer
added
the
kCTF: vuln OK
koczkatamas
left a comment
koczkatamas
left a comment
There was a problem hiding this comment.
Hey! I've left some questions, change requests and also run our AI tool on the source code. Please take a look and make changes if necessary. Thanks!
pocs/linux/kernelctf/CVE-2024-45016_lts_cos_mitigation/exploit/cos-109-17800.218.76/exploit.c
Outdated
Show resolved
Hide resolved
pocs/linux/kernelctf/CVE-2024-45016_lts_cos_mitigation/exploit/cos-109-17800.218.76/exploit.c
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| if (off != -1) { | ||
| memcpy(buf, msgbuf + off + 56, 8); // latency |
There was a problem hiding this comment.
Could you describe what structure's fields you are describing here? Are they dynamically generated fields and they don't have a kernel representation?
Asking because we'd like to understand how to modify these offsets when we'd like to target a different kernel version.
Read more about this violation in the 'Sprayed and leaked structures' section of the style guide.
There was a problem hiding this comment.
There is no underlying struct, the message is constructed in netem_dump() and has to be parsed.
pocs/linux/kernelctf/CVE-2024-45016_lts_cos_mitigation/exploit/cos-109-17800.218.76/exploit.c
Outdated
Show resolved
Hide resolved
pocs/linux/kernelctf/CVE-2024-45016_lts_cos_mitigation/exploit/cos-109-17800.218.76/exploit.c
Outdated
Show resolved
Hide resolved
pocs/linux/kernelctf/CVE-2024-45016_lts_cos_mitigation/exploit/mitigation-v3-6.1.55/exploit.c
Outdated
Show resolved
Hide resolved
pocs/linux/kernelctf/CVE-2024-45016_lts_cos_mitigation/exploit/mitigation-v3-6.1.55/exploit.c
Outdated
Show resolved
Hide resolved
|
|
||
| ``` | ||
| y,p: &n2->latency | ||
| s: &n1->latency + 32 |
There was a problem hiding this comment.
What's at +32 or why do we need this offset?
There was a problem hiding this comment.
The node s is placed there so that its child fields overlap with controllable parameters.
| Due to the limitation of the rebalancing write mentioned above, the fake qdisc linked to by `n2->hash.next` will be at a misaligned offset, limiting which of its fields we can set. Therefore this qdisc will only be used to link to the fake qdisc that is actually used for the read. Here are the `y`,`p`,`s`,`c` addresses for the rebalancing write: | ||
|
|
||
| ``` | ||
| y: &n1->latency + 32 |
There was a problem hiding this comment.
What are at offsets +32, +32 and +8 or why do we need this alignment?
There was a problem hiding this comment.
y has to be at the same place as the previous s to stay under the dangling rb_node pointer. A fake Qdisc will placed with its hash.next at p. Its location is chosen so that we can control its hash.next and flags fields. s is again chosen so that its child fields are controllable.
| The rebalancing write primitive is used to replace the root FSC `hfsc_class` of the interface's root qdisc: | ||
|
|
||
| ``` | ||
| y: &n1->slot + 8 |
There was a problem hiding this comment.
What are at offsets +8, -16 and +32 or why do we need this alignment?
There was a problem hiding this comment.
y has to be at the same place as the previous s to stay under the dangling rb_node pointer. The vt_node of a fake hfsc_class will be located at p. It's placed so that its left child field overlaps with the parameters. s is at the same location as in the first write.
I've defined macros for the offsets to indicate which fake structure is placed at them. They are offset by one byte to account for the node being colored black during the write.
|
Hey! A few comments left unanswered, are you still planning to make changes before we can review it? |
3 participants
No description provided.