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@xxxxxxxxxx> 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@xxxxxxxxxx> wrote: > > > > On Tue, Nov 19, 2024 at 9:54 AM Max Kellermann <max.kellermann@xxxxxxxxx> wrote: > > > > > > On Tue, Nov 19, 2024 at 2:58 PM Patrick Donnelly <pdonnell@xxxxxxxxxx> 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 > > > >
