linux-kernel - Re: [PATCH 3.13 163/163] lzo: check for length overrun in variable length encoding.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141013184853.GD30087@1wt.eu>
Date:	Mon, 13 Oct 2014 20:48:53 +0200
From:	Willy Tarreau <w@....eu>
To:	Kamal Mostafa <kamal@...onical.com>
Cc:	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	kernel-team@...ts.ubuntu.com,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 3.13 163/163] lzo: check for length overrun in variable length encoding.

Hi Kamal,

On Mon, Oct 13, 2014 at 10:31:03AM -0700, Kamal Mostafa wrote:
> > This one (and the accompanying revert) are still not present in more
> > recent stable kernels, so I find it surprizing that you're proposing
> > to integrate them now.
> 
> I can hold out those lzo fixes until the next 3.13-stable if you prefer.

It would be better in my opinion.

> But fwiw...
> 
> >  If someone upgrades from 3.13.11.9 to 3.14.21
> > or 3.16.5, they'd expect to keep all fixes but will lose this one, so
> > this is a bit confusing.
> 
> I think those sorts of scheduling mismatches and discrepancies between
> stable versions are pretty common.

I don't think so. In my opinion when this happens it's mostly a mistake.

> Examples:  The top 11 commits in
> v3.12.30 have not yet been applied[0] to any of the newer stable
> branches;

I think this doesn't happen often and probably it's just a matter of
reporting it when it happens so that maintainers double-check on their
side.

> Many of the commits in v3.10.57 have not yet been applied[1]
> to linux-3.12.y but have been released in other newer stables.

In Jiri's defense, he's in the middle of two versions managed by Greg,
so when Greg sends a batch of 3.10+3.14 releases, there is a small
window where 3.12 can be lagging a bit. But I think that this is
different from having patches that are not in the most recent
versions because users are much less likely to upgrade from one of
Greg's maintained kernels to any of ours than the opposite.

> >  Is there any reason you're not tracking fixes
> > from more recent versions like Jiri, Li, Ben and I are doing ?
> 
> We (the Canonical stable maintainers) have always tracked the "cc:
> stable" fixes directly from mainline, not from the more-recent-version
> branches.  Given the examples above, it seems that the kernel.org
> maintainers are doing that too, yes?

Possible, I don't know for others though I know that Greg tends to
be picky about mistakes like this not to happen too often, so I
suspect there's a bit of care there. I'm personally in a special
situation considering that I'm on the tail so the amount of changes
to apply to certain patches to backport them suggests that I more
often pick them from 3.2 or 3.4 than mainline (except for the ones
that I receive directly).

I can't speak for Greg but I think that sometimes if you notice that
you're merging a patch which is missing in most recent -stable branches,
it would be nice to send a reminder about it, as it's certainly possible
that one slips through from time to time.

Thanks,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/