[CHECKER] race in 2.5.62/fs/exec.c?

[CHECKER] race in 2.5.62/fs/exec.c?

[Dawson Engler]

I'm not sure if I'm missing something --- is the following a race?

           2.5.62/fs/exec.c:1013:search_binary_handler:
                        read_unlock(&binfmt_lock);
                        retval = fn(bprm, regs);
                        if (retval >= 0) {
                                put_binfmt(fmt);

binfmt_lock is released and then put_binfmt is called.  put_binfmt
seems to need locking:

    fs/exec.c:1022:search_binary_handle

                        read_lock(&binfmt_lock);
                        put_binfmt(fmt);
                        if (retval != -ENOEXEC)
                                break;
                        if (!bprm->file) {
                                read_unlock(&binfmt_lock);
                                return retval;
                        }


   2.5.62/fs/exec.c:151:sys_uselib:

                     error = fmt->load_shlib(file);
                        read_lock(&binfmt_lock);
                        put_binfmt(fmt);
                        if (error != -ENOEXEC)
                                break;
                }

Are these other locks redundant?  Or does put_binfmt need protection?

Re: [CHECKER] race in 2.5.62/fs/exec.c?

[Andrew Morton]

Dawson Engler <engler@csl.stanford.edu> wrote:
>
> I'm not sure if I'm missing something --- is the following a race?
> 
>            2.5.62/fs/exec.c:1013:search_binary_handler:
>                         read_unlock(&binfmt_lock);
>                         retval = fn(bprm, regs);
>                         if (retval >= 0) {
>                                 put_binfmt(fmt);

Don't think so.

That lock protects the global list of registered formats only.  Because we
have a ref against the format's underlying module when that lock is dropped,
the module cannot be unloaded and nobody can unregister the format.  Hence
the thing at *fmt is stable, and reading fmt->next after retaking the lock is
safe.

The particular piece of code you quote would be buggy if it continued
to go around the loop and again used fmt->next.  But it will unconditionally
return after performing the put_binfmt() call.