@mruffell Thanks for checking this.
When I prepared this patch, I ran the same test against Jammy, but I could not reproduce the issue. Jammy still uses the older bipbuffer implementation, so I don't think it is affected by the heap buffer overflow fixed by this SRU. The older Jammy path can still wait indefinitely for a non-reading client. Upstream commit a22be2bd removed that path as part of a larger crawler buffer redesign, but that redesign also introduced the heap buffer overflow fixed by 7eeac6e9. So I think the Jammy issue should be handled separately with a smaller Jammy specific fix rather than backporting the full buffer redesign.(quite big patch..) The error path fixed by ea35f441 also appears to be relevant to Jammy and can be reviewed as part of that separate LP. https://github.com/memcached/memcached/commit/a22be2bdbff1bb80be87071aad1caf648d15722b https://github.com/memcached/memcached/commit/7eeac6e9a9945aa68298aff379cea5ab3817af7c https://github.com/memcached/memcached/commit/ea35f441f265b4aef3f7753aa5cbb87d99859123 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2161693 Title: memcached: heap buffer overflow in LRU crawler dump (lru_crawler metadump) on an idle client To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/memcached/+bug/2161693/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
