<div dir="auto"><div>Thank you,<div dir="auto"><br></div><div dir="auto">I understand and it makes sense.</div><div dir="auto"><br></div><div dir="auto">Do you have any advice for how third party modules could acheive the same? The blocked field might be safe to use within other phases but it's difficult to fully verify.</div><div dir="auto"><br></div><div dir="auto">I'm no longer using that module (having found an alternative) but I'm willing to push an issue to them in the spirit of oss.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Perhaps a comment in the nginx developer docs regarding the correct way to get memory for a thread pool task would be a good idea? It seems like a common problem for which there is limited examples for reference.</div><div dir="auto"><br></div><div dir="auto">Thanks again for your help Maxim</div><div dir="auto"><br></div><div dir="auto">- Mathew </div><div dir="auto"><br></div><div dir="auto"><br></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 31 May 2023, 12:15 pm Maxim Dounin, <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<br>
On Wed, May 31, 2023 at 01:26:35AM +1000, Mathew Heard wrote:<br>
<br>
> I've been going through the threadpool code for native modules in an<br>
> attempt to fix a third party module with what appears to be a<br>
> use-after free error looking for inspiration.<br>
> <br>
> I thought I would see a strategy to prevent thread pool tasks that are<br>
> in the queue for processing being freed when the request / connection<br>
> their memory is allocated from is cleared but I'm not.<br>
> <br>
> For example there does not for example appear to be any protection<br>
> against linux sendfile tasks from reading memory allocated from the<br>
> ngx_connection_t if the connection is closed while the task is in the<br>
> task queue.<br>
> <br>
> Is this correct? Is this a bug?<br>
<br>
As long as there is a thread task or an AIO request scheduled, the <br>
request is expected to be blocked with r->blocked, so it won't be <br>
freed.<br>
<br>
For sendfile in threads, this is done by <br>
ngx_http_copy_thread_handler() (in <br>
src/http/ngx_http_copy_filter_module.c), which is called by <br>
ngx_linux_sendfile_thread() as file->file->thread_handler() when a <br>
sendfile task is queued.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank" rel="noreferrer">nginx-devel@nginx.org</a><br>
<a href="https://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer noreferrer" target="_blank">https://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div></div></div>