Hey, Folks. This seems important, so I'm bumping this thread. Max has a valid concern, and this issue must be addressed. Jeff seems to think keeping at least a few retries might be a good idea.
Max, could you add a cap on the retry count to your original patch? I will discuss the PATH_MAX with Patrick and open a feature request for myself to alleviate the limitation.
On Thu, Nov 21, 2024 at 12:48 PM Alex Markuze amarkuze@redhat.com wrote:
IMHO, we should first have a solution for the immediate problem, remove infinite retries and fail early, and cap it at 3 retries in case there is a temporary issue here. I would use ENAMETOOLONG as the primary error code, as it is the most informative, and couple it with a rate-limited kernel log (pr_warn_once) for debugging without flooding. I would also open a bug/feature request for a dynamic buffer allocation that bypasses PATH_MAX for protocol-specific paths.
On Tue, Nov 19, 2024 at 5:17 PM Patrick Donnelly pdonnell@redhat.com wrote:
On Tue, Nov 19, 2024 at 9:54 AM Max Kellermann max.kellermann@ionos.com wrote:
On Tue, Nov 19, 2024 at 2:58 PM Patrick Donnelly pdonnell@redhat.com wrote:
The protocol does **not** require building the full path for most operations unless it involves a snapshot.
We don't use Ceph snapshots, but before today's emergency update, we could shoot down an arbitrary server with a single (unprivileged) system call using this vulnerability.
I'm not sure what your point is, but this vulnerability exists, it works without snapshots and we think it's serious.
I'm not suggesting there isn't a bug. I'm correcting a misunderstanding.
-- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D