[SRU Bionic 0/5] CVE-2023-32233

[Stefan Bader]

On 17.05.23 14:18, Thadeu Lima de Souza Cascardo wrote:
> On Wed, May 17, 2023 at 02:13:17PM +0200, Stefan Bader wrote:
>> On 17.05.23 13:55, Thadeu Lima de Souza Cascardo wrote:
>>> On Wed, May 17, 2023 at 09:18:38AM +0200, Stefan Bader wrote:
>>>> On 16.05.23 15:53, Thadeu Lima de Souza Cascardo wrote:
>>>>> [Impact]
>>>>> On systems where user namespaces can be created by unprivileged users,
>>>>> which is the default configuration on Ubuntu, unprivileged users can
>>>>> trigger a use-after-free vulnerability on netfilter. This could be used to
>>>>> crash the system or elevate privileges.
>>>>>
>>>>> [Test case]
>>>>> A reproducer that causes an oops under slub_debug=FZP was tested and the fix
>>>>> has been shown to prevent it.
>>>>>
>>>>> [Backport]
>>>>> Picked patches submitted by the maintainer to 4.14 tree.
>>>>>
>>>>> [Potential impact]
>>>>> netfilter users may find regressions when manipulating nftables.
>>>>>
>>>>> Florian Westphal (1):
>>>>>      netfilter: nf_tables: split set destruction in deactivate and destroy
>>>>>        phase
>>>>>
>>>>> Pablo Neira Ayuso (4):
>>>>>      netfilter: nf_tables: unbind set in rule from commit path
>>>>>      netfilter: nf_tables: use-after-free in failing rule with bound set
>>>>>      netfilter: nf_tables: bogus EBUSY when deleting set after flush
>>>>>      netfilter: nf_tables: deactivate anonymous set from preparation phase
>>>>>
>>>>>     include/net/netfilter/nf_tables.h |  30 ++++++-
>>>>>     net/netfilter/nf_tables_api.c     | 139 +++++++++++++++++++++---------
>>>>>     net/netfilter/nft_dynset.c        |  22 ++++-
>>>>>     net/netfilter/nft_immediate.c     |   6 +-
>>>>>     net/netfilter/nft_lookup.c        |  21 ++++-
>>>>>     net/netfilter/nft_objref.c        |  21 ++++-
>>>>>     6 files changed, 193 insertions(+), 46 deletions(-)
>>>>>
>>>>
>>>> All patches seem to miss the cherry pick/backport line. As we probably also
>>>> should start handling bionic like ESM, maybe this should be re-submitted
>>>> with fixed provenance to the ESM list. Not NACKing straight to leave the
>>>> option for alternatives.
>>>> -- 
>>>> - Stefan
>>>>
>>>
>>> Provenance here is stated on the "[Upstream commit SHA1]" lines at the top,
>>> just like other fixes coming from upstream stable. As stated in the cover
>>> letter, these were picked as submitted by the maintainer to the stable 4.14.y
>>> series, hence the provenance as is.
>>
>> The format like stable would suggest some stable but then not clearly which
>> one. I realize that the stable series patches are done without that. But
>> then at least have a tracking bug that tellls from where things come and
>> also have a final commit which shows the upstream heritage.
>> Information from the cover email gets lost in the tree itself. And take some
>> comments as the pick was done before actually landing in 4.14.y. In this
>> case I probably still would have added cherry pick lines but saying
>> something from linux4.14.y submission). So we retrain the special way of
>> getting them.
> 
> What about a Link: pointing out to lore, as upstream has been using? That would
> be one step further than using the Message-ID, as those links include those.

Anything that reminds us about where something came from within the 
commit itself is good. Just not get into a situation where we ask 
ourselves where the heck this came from.
> 
> In this particular case, there is where they came from, a mailbox, not a git
> repo, so there would be no SHA1 to use, except one I created myself when
> applying the fix myself.
> 
> Cascardo.
> 
>>>
>>> Just like with the other changes that come from upstream stable, this works
>>> (and should, otherwise it would fail with those changes) for our tooling.
>>>
>>> And since these are targeted to be released before May 31st, when Bionic goes
>>> into ESM, I opted to handle this as usual.
>>>
>>> Cascardo.
>>
>> -- 
>> - Stefan
>>
> 
> 
> 
> 
> 

-- 
- Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 44613 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20230517/167593da/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20230517/167593da/attachment-0001.sig>