Re: [PATCH v1] io_uring: fix dangling iovec after provided-buffer bundle grow failure
Jens Axboe <[email protected]> Mon, 6 Jul 2026 12:06:45 -0600
| Newsgroups | org.kernel.vger.io-uring,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 7/6/26 11:46 AM, Hao-Yu Yang wrote: > On Mon, Jul 06, 2026 at 11:39:14AM -0600, Jens Axboe wrote: >> On 7/6/26 11:34 AM, Hao-Yu Yang wrote: >>> On Mon, Jul 06, 2026 at 11:13:55AM -0600, Jens Axboe wrote: >>>> On 7/6/26 11:01 AM, Hao-Yu Yang wrote: >>>>> Sorry, i forgot to cc others mail >>>>> >>>>> I discovered and wrote the PoC myself. Trigger way is >>>>> send1: Submit an IORING_OP_SEND request with four valid >>>>> provided buffers. The system will allocate and cache an >>>>> iovec array (of size 4) for this request and store the >>>>> pointer in kmsg->vec.iovec. >>>>> >>>>> send2: Submit a second send request with 8, and I set >>>>> the fourth passed-in address to point to an invalid address. >>>>> Now kmsg still hold old iovec, but old iovec object have >>>>> been freed. >>>>> >>>>> So this will lead dangling pointer. >>>> >>>> Side note: please don't top post, linux mailing lists always reply >>>> under the text for better readability. Top posting turns any kind >>>> of threaded conversation into both a mess, and it's also wasteful. >>>> >>>> Great thanks! Want to turn this into a liburing test case? Then we can >>>> include it there as well, and it'd catch both UAF and memory leaks when >>>> run. >>>> >>>> -- >>>> Jens Axboe >>> >>> How to turn this into a liburing test case? Should this be included in >>> the v2 patch? >> >> Look at the tests in test/ in liburing. Or just send the reproducer and >> I can get it turned into a test case. >> >> Should be separate from a kernel patch, it's a patch for an entirely >> different repository. >> >> >> -- >> Jens Axboe > > OK, I will send v2 patch first when i wake up. And I now my PoC to > trigger this KASAN have became a exploit can use to priviledge > escalation. I think i should send this script to your email? (not > included any public gmail?) Like I said in my original reply, there's no security concerns here, as the code in question is NOT IN A RELEASED kernel. It only exists in the 7.2-rc kernels, and the kernel documentation will tell you that unless it's in a released kernel, it's not a security issue. -- Jens Axboe