12:00:48 <jki> #startmeeting CIP IRC weekly meeting
12:00:48 <collab-meetbot> Meeting started Thu Apr 30 12:00:48 2026 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:48 <collab-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:48 <collab-meetbot> The meeting name has been set to 'cip_irc_weekly_meeting'
12:00:55 <jki> #topic AI review
12:01:02 <jki> again: none
12:01:08 <jki> 5
12:01:10 <jki> 4
12:01:12 <jki> 3
12:01:14 <jki> 2
12:01:15 <jki> 1
12:01:18 <jki> #topic Kernel maintenance updates
12:01:40 <uli_> i pushed 4.4
12:01:43 <masami> This week reported 163 new CVEs and 60 updated CVEs.
12:02:09 <iwamatsu> I was unable to work on the review this week.
12:02:16 <pave1> I did some reviews: 6.12.84, .83 and .82
12:03:22 <masami> fyi: I have confirmed that the Copy Fail PoC works with versions 4.19.325-cip130-st14 and 5.10.252-cip71.
12:03:56 <masami> I haven't tested with 6.1 yet.
12:04:11 <pave1> Local root. World is not ending, but this one has high publicity...
12:04:15 <jki> which PoC exactly?
12:04:22 <pave1> ...and a name :-)
12:04:25 <pave1> CVE-2026-31431.
12:04:29 <masami> https://copy.fail/#exploit this one.
12:04:48 <jki> yes, it's more on the visibility side
12:05:10 <jki> older systems used to have less local exploit vectors then todays systems have
12:05:31 <jki> so, were is upstream with backporting?
12:05:37 <jki> I lost overview
12:05:48 <jki> and what are we doing right now?
12:06:15 <pave1> I tried backporting, and it turned out not to be trivial.
12:06:33 <jki> and LTS has the fix in... ?
12:07:10 <pave1> This may help:
12:07:12 <pave1> https://lore.kernel.org/stable/2026043003-skier-sprint-7b88@gregkh/T/#t
12:07:43 <jki> so, down to 5.10 should come via LTS for us
12:07:52 <jki> only 4.19 then our business, right?
12:08:10 <pave1> Yes.
12:08:12 <jki> BTW, Debian is waiting as well: https://security-tracker.debian.org/tracker/CVE-2026-31431
12:08:14 <arisut> just disable it
12:08:26 <jki> do we have it enabled in our configs?
12:08:47 <arisut> https://paste.gentoo.zip/tnMM73Xk
12:09:04 <pave1> I believe so. At least that's what review scripts were telling me.
12:09:58 <jki> can it be .config-wise disabled as well without breaking too much?
12:10:32 <arisut> need to disable authencesn
12:10:51 <iwamatsu> AF_ALG?
12:10:59 <pave1> CONFIG_CRYPTO_AUTHENC. I have not known about it before the exploit :-)
12:11:15 <jki> use cases?
12:11:45 <iwamatsu> CONFIG_CRYPTO_AUTHENC is enabled on cip-kernel-configs
12:11:49 <jki> quite a few "select" in the kernel...
12:11:49 <pave1> Kconfig help says: Authenc: Combined mode wrapper for IPsec. This is required for IPSec ESP (XFRM_ESP).
12:12:04 <jki> IPsec - was already suspecting this
12:13:08 <jki> I bet we have users who would shout out, "I need it", even if not all
12:13:34 <jki> CONFIG_MAC802154 selects it as well
12:13:55 <pave1> We still should teach our users not to enable things they don't need, but that's long term project.
12:14:14 <jki> sure - they will learn eventually ;)
12:14:27 <pave1> Or their customers will :-)
12:14:45 <arisut> patches are already in in the latest kernels https://kernel.org/
12:14:54 <pave1> I don't believe it is worth press release "run and disable CRYPTO_AUTHENC because sky is falling"
12:15:12 <pave1> ...before by the time they disable the config, better solution will be already available.
12:15:22 <jki> nope, but some posting on the mailing list would be good
12:15:33 <jki> we could communicate the workaround(s) now and ask for demand of faster fixes
12:15:48 <jki> while waiting for 5.10 to settle and developing/testing 4.19 fix
12:16:09 <jki> once the fixes are in our tree, we can communicate again and only then decide whether to release earlier
12:16:33 <pave1> So... 6.12.85 is out, mostly crypto changes. I believe that's related.
12:16:34 <jki> several releases are due mid of May
12:17:19 <jki> anyway, I think communicating is key unless we already consider this super-critical
12:17:27 <jki> which does not seem to be the case
12:17:32 <pave1> 5.10.254 is out, too.
12:17:48 <pave1> Well, I did "Copy fail" -- Fun CVE -- CVE-2026-31431" post :-)
12:18:28 <jki> yes, but also share more more structured overview
12:18:38 <jki> for workarounds and for our patching status
12:18:53 <jki> 5.10.254 is fixed, newer ones then as well
12:18:56 <pave1> I don't believe it is super-critical, but I believe simply doing the -cip releases is the easiest way to go forward.
12:19:13 <uli_> ftr, 5.10.253 is large, so 4.19 is not going to be an early release this time
12:19:31 <uli_> if it's supposed to be quick i'd have to leave 253 patches and do one based on 254 only instead
12:19:49 <jki> we could pull the fix early into 4.19 and do the rest later
12:20:01 <pave1> uli: That would be the way to do it. I don't believe .254 changes depend on anything in .253.
12:20:01 <iwamatsu> +1
12:20:11 <uli_> i think so, too
12:20:15 <jki> if we do earlier releases for the other CIP kernels, 4.19 should be treated similar
12:20:26 <jki> unless there are technical complications
12:21:03 <jki> so, who will look into the 4.19 backport?
12:21:10 <pave1> I believe we can do -cip releases fairly easily. -cip-rt may be more tricky.
12:21:11 <arisut> 6.12 backports: https://lore.kernel.org/stable/20260430060702.110091-1-ebiggers@kernel.org/
12:21:11 <arisut> 6.1 backports: https://lore.kernel.org/stable/20260430062731.140497-1-ebiggers@kernel.org/
12:21:38 <jki> -rt could be handled like 4.19: no baseline updates
12:21:54 <uli_> jki: i will, i guess. it's in the pipeline anyway
12:22:17 <jki> uli_; thanks!
12:23:10 <jki> then we agree to give this fix prio in our queues and try to update all CIP kernels?
12:23:11 <pave1> jki: In emergency, that probably can be done, but ... just trying to do the regular way would be preffered option.
12:23:46 <uli_> +1
12:23:58 <pave1> I think that's best. I can simply go 6.12-cip, 6.1-cip, 5.10-cip and then figure out what to do with -rt.
12:24:23 <iwamatsu> +1
12:24:45 <jki> great
12:25:09 <jki> hope this does not ruin anyone's long weekend
12:25:18 <jki> (where there is one)
12:25:42 <pave1> Should I write some kind of "Copy fail is bad, disable CONFIG_foo especially on -rt, expect out of schedule kernels"?
12:25:54 <pave1> email?
12:26:04 <jki> +1 - thanks!
12:26:42 <jki> more on this? or other maintenance topics?
12:27:09 <jki> 5
12:27:12 <jki> 4
12:27:14 <jki> 3
12:27:16 <jki> 2
12:27:18 <jki> 1
12:27:21 <jki> #topic Kernel release status
12:27:31 <jki> all green
12:27:42 <jki> rest we just discussed
12:27:50 <jki> 5
12:27:53 <jki> 4
12:27:54 <jki> 3
12:27:56 <jki> 2
12:27:59 <jki> 1
12:28:01 <jki> #topic Kernel testing
12:28:56 <arisut> nothing from me
12:29:01 <pave1> 7.0.3 is out; if we are testing it somewhere, tell me url :-)
12:30:22 <jki> anything else on testing?
12:30:38 <arisut> pave1, I'm currently fixing gentoo sources vulnerabilities
12:31:07 <arisut> for 7.0,3 testing I think you could look KernelCI as usual
12:31:13 <pave1> ok, I'll ask again next week :-)
12:31:41 <pave1> I'd like https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-7.0.y
12:33:12 <iwamatsu> We don't have it, so we need to create it...
12:36:19 <jki> so, $someone will do it once there is time ;)
12:36:36 <jki> anything else?
12:36:56 <arisut> most of the recent kernel added commit a664bf3d603d
12:37:09 <arisut> t reverts the 2017 algif_aead in-place optimization, so page-cache pages can no longer end up in the writable destination scatterlist. Most major distributions are shipping the fix now.
12:37:35 <jki> yes, this is what we discussed before, I think
12:37:54 <pave1> Yep. That's the "copy fail" fix. Optimalization was bogus, anyway, so I don't expect performance regressions.
12:38:23 <arisut> looks now added on all new kernels
12:38:34 <jki> down to 5.10, see above
12:38:47 <arisut> yes
12:39:16 <jki> so, anything else on /testing/? ;)
12:39:47 <arisut> you can use the patch I linked for above for disabling authencesn.o on older kernels
12:40:01 <jki> why? we have the reverts
12:40:13 <pave1> Lets discuss that at aob session or after the meeting.
12:40:37 <jki> then let's move to aob - unless there is more on testing...
12:40:49 <jki> 5
12:40:52 <jki> 4
12:40:54 <jki> 3
12:40:55 <jki> 2
12:40:57 <jki> 1
12:40:59 <jki> #topic AOB
12:41:15 <jki> thanks for the first config extension feedback!
12:41:25 <pave1> arisut: Yes, that can be done, but that's quite a hack, and proper solution is as easy.
12:41:39 <arisut> pave1, ok
12:42:14 <pave1> jki: Sorry for taking time. That pc104 stuff scares me a bit (I thought it must have been a mistake) -- that's old hardware, but we should be able to do it.
12:42:28 <arisut> can you add also me in copy on the email/patch with the solution
12:43:01 <jki> pavel: if you see any noteworthy effort increase as well, let me know
12:43:33 <jki> there are more questions/wishes coming, I'm moderating them first
12:43:45 <pave1> arisut: We'll just update to latest stable kernels. There were released in last few hours, and they fix just this.
12:44:06 <pave1> jki: ok, but I don't expect much effort increase. It was just strange.
12:44:07 <arisut> pave1, what about older cip kernels ?
12:44:40 <pave1> arisut: Down to 5.10, we have -stable fixes. For 4.19, we backport fixes from stable. 4.4 is not affected.
12:45:19 <arisut> yes, I was meaning the 4.19 backport
12:48:10 <jki> other topics?
12:48:46 <pave1> uli will be doing that. We hope 5.10 patches will simply apply. If not, we try to fit them
12:48:58 <pave1> as usual, if that's impossible, we can probably just disable that, too.
12:50:26 <jki> so...
12:50:34 <arisut> jki, not from me I'm going back to pushing gentoo sources
12:51:17 <jki> then let's close
12:51:20 <jki> 5
12:51:22 <jki> 4
12:51:24 <jki> 3
12:51:25 <jki> 2
12:51:27 <jki> 1
12:51:28 <jki> #endmeeting