[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2792: -- Labels: review (was: ) Large request header causes unexpected remap Key: TS-2792 URL: https://issues.apache.org/jira/browse/TS-2792 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Assignee: Brian Geffon Priority: Critical Labels: review Fix For: 5.0.0 Attachments: quickfix.diff I get unexpected remap result when I request with likely 4KB of header. It seems to be caused by coalescing of heaps. In url_rewrite_remap_request, requestPath points to the path string of the URL. However, the address of the string may be changed in remap process in this function (e.g. request_url-host_set()). Because large header uses lots of space so reallocation of heap may be caused when we modify the header values. So the memcpy in this function may use the old invalid address as a source, and it results unexpected remap and also results broken log outputs. It may not cause crashes, but works incorrectly. How to reproduce: It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-2792: Summary: Large request header causes unexpected remap (was: Large request header occurs unexpected remap) Large request header causes unexpected remap Key: TS-2792 URL: https://issues.apache.org/jira/browse/TS-2792 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Attachments: quickfix.diff I get unexpected remap result when I request with likely 4KB of header. It seems to be caused by coalescing of heaps. In url_rewrite_remap_request, requestPath points to the path string of the URL. However, the address of the string may be changed in remap process in this function (e.g. request_url-host_set()). Because large header uses lots of space so reallocation of heap may be caused when we modify the header values. So the memcpy in this function may use the old invalid address as a source, and it results unexpected remap and also results broken log outputs. It may not cause crashes, but works incorrectly. How to reproduce: It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-2792: Attachment: (was: quickfix.diff) Large request header causes unexpected remap Key: TS-2792 URL: https://issues.apache.org/jira/browse/TS-2792 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Fix For: 5.0.0 I get unexpected remap result when I request with likely 4KB of header. It seems to be caused by coalescing of heaps. In url_rewrite_remap_request, requestPath points to the path string of the URL. However, the address of the string may be changed in remap process in this function (e.g. request_url-host_set()). Because large header uses lots of space so reallocation of heap may be caused when we modify the header values. So the memcpy in this function may use the old invalid address as a source, and it results unexpected remap and also results broken log outputs. It may not cause crashes, but works incorrectly. How to reproduce: It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Masakazu Kitajo updated TS-2792: Attachment: quickfix.diff I replaced the last patch. In case of that coalesce_str_heaps() is called in request_url-host_set(), the requestPath variable no longer points to correct address which the request path is stored. port_set() and scheme_set() have same possibility. The case happens under these conditions: - The request header size is over 4096. - In url_rewrite_remap_request(), the sum of toSchemeLen and toHostLen is more than request_url-m_heap-m_read_write_heap).m_free_size. So, we should call the request_url-path_get() after the scheme_set(). Large request header causes unexpected remap Key: TS-2792 URL: https://issues.apache.org/jira/browse/TS-2792 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Fix For: 5.0.0 Attachments: quickfix.diff I get unexpected remap result when I request with likely 4KB of header. It seems to be caused by coalescing of heaps. In url_rewrite_remap_request, requestPath points to the path string of the URL. However, the address of the string may be changed in remap process in this function (e.g. request_url-host_set()). Because large header uses lots of space so reallocation of heap may be caused when we modify the header values. So the memcpy in this function may use the old invalid address as a source, and it results unexpected remap and also results broken log outputs. It may not cause crashes, but works incorrectly. How to reproduce: It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2792: -- Assignee: Brian Geffon Large request header causes unexpected remap Key: TS-2792 URL: https://issues.apache.org/jira/browse/TS-2792 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Assignee: Brian Geffon Priority: Critical Fix For: 5.0.0 Attachments: quickfix.diff I get unexpected remap result when I request with likely 4KB of header. It seems to be caused by coalescing of heaps. In url_rewrite_remap_request, requestPath points to the path string of the URL. However, the address of the string may be changed in remap process in this function (e.g. request_url-host_set()). Because large header uses lots of space so reallocation of heap may be caused when we modify the header values. So the memcpy in this function may use the old invalid address as a source, and it results unexpected remap and also results broken log outputs. It may not cause crashes, but works incorrectly. How to reproduce: It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2792) Large request header causes unexpected remap
[ https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-2792: -- Priority: Critical (was: Major) Large request header causes unexpected remap Key: TS-2792 URL: https://issues.apache.org/jira/browse/TS-2792 Project: Traffic Server Issue Type: Bug Affects Versions: 4.0.2, 5.0.0 Reporter: Masakazu Kitajo Priority: Critical Fix For: 5.0.0 Attachments: quickfix.diff I get unexpected remap result when I request with likely 4KB of header. It seems to be caused by coalescing of heaps. In url_rewrite_remap_request, requestPath points to the path string of the URL. However, the address of the string may be changed in remap process in this function (e.g. request_url-host_set()). Because large header uses lots of space so reallocation of heap may be caused when we modify the header values. So the memcpy in this function may use the old invalid address as a source, and it results unexpected remap and also results broken log outputs. It may not cause crashes, but works incorrectly. How to reproduce: It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of header causes this problem. -- This message was sent by Atlassian JIRA (v6.2#6252)
