12:01:11 <jki> #startmeeting CIP IRC weekly meeting
12:01:11 <collab-meetbot`> Meeting started Thu May 14 12:01:11 2026 UTC and is due to finish in 60 minutes.  The chair is jki. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:11 <collab-meetbot`> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:11 <collab-meetbot`> The meeting name has been set to 'cip_irc_weekly_meeting'
12:01:16 <jki> #topic AI review
12:01:21 <jki> none
12:01:26 <jki> 5
12:01:28 <jki> 4
12:01:29 <jki> 3
12:01:31 <jki> 2
12:01:32 <jki> 1
12:01:35 <jki> #topic Kernel maintenance updates
12:01:50 <masami> This week reported 215 new CVEs and 7 updated CVEs.
12:01:51 <uli_> i'm working on the next 4.4
12:02:48 <iwamatsu> I reiviewed 6.12.82.
12:03:05 <jki> what's the state of dirty frag and the rxrpc thing in our queues?
12:03:45 <uli_> 4.19 is affected by one of the two issues; the 5.10 patch applies without changes
12:03:48 <uli_> 4.4 is not affacted
12:03:51 <uli_> affected
12:04:19 <pave1> I am reviewing 6.12.68, .88
12:05:08 <jki> so, handle like copy fail and release earlier as well?
12:05:22 <jki> all stable kernels should be fixed by now IIUC
12:05:35 <jki> or only propose mitigations to our users (disable feature/module)?
12:05:45 <pave1> We probably should do that.
12:06:07 <pave1> Releases.
12:06:15 <iwamatsu> +1
12:06:29 <jki> ok
12:06:30 <uli_> no opinion myself, i'm ok either way
12:06:37 <pave1> It would help if we knew if there's another one
12:06:42 <pave1> pending.
12:07:11 <uli_> there is cve-2026-46300
12:07:18 <uli_> fix is not in mainline yet
12:07:29 <masami> yes. it is another Dirty Frag vulnerability class
12:07:34 <jki> which one is that?
12:07:54 <iwamatsu> https://github.com/v12-security/pocs/tree/main/fragnesia
12:09:00 <masami> mitigation is same as for dirtyfrag
12:09:29 <jki> "nice"
12:09:44 <jki> is a patch under discussion at least?
12:10:22 <uli_> https://lists.openwall.net/netdev/2026/05/13/79
12:10:57 <jki> just spotted it, looking for a thread now
12:11:17 <jki> well, might be worth to wait a day then, no?
12:11:23 <uli_> i would say so
12:11:29 <pave1> agreed.
12:12:54 <jki> but the other fixes could be staged already
12:13:05 <jki> okay (or not...)
12:13:22 <jki> more on maintenance?
12:13:38 <patersonc> cbeznea_ posted a fix for the USB issue that is broken currently in CIP 5.10: https://lore.kernel.org/all/20260514111300.2152386-1-claudiu.beznea@kernel.org/. Do we want to fix something directly in CIP? Or wait for it to filter through LTS? I'm keen to get CIP booting again...
12:15:07 <iwamatsu> We need to wait for the LTS version that apply it.
12:15:24 <pave1> We should probably merge something before next release.
12:16:46 <iwamatsu> If it's applied , should we cherry-pick it without waiting for LTS?
12:17:06 <patersonc> LTS would probably be faster than getting it into mainline :)
12:17:45 <pave1> I'd say so. We have regression on supported board.
12:17:59 <pave1> We can make exceptions here.
12:18:10 <cbeznea_> the stable v5.10 backport that triggered the issue we are seeing currently with CIP 5.10 was wrong, as Pavel pointed out in the thread https://lore.kernel.org/all/20260501225859.504868-1-nobuhiro.iwamatsu.x90@mail.toshiba . Maybe we could pick this small fix until the mainline is fixed. The USB PHY tend to be slow even for fixes
12:18:19 <jki> so, the workaround of spinning instead of sleeping was not accepted?
12:19:19 <jki> IIRC, that was only aligning to current mainline, and it would be gone again after that more complex solution above is accepted
12:19:44 <cbeznea_> I checked 5.10 stable trees few days ago but didn't notice any fix integrated
12:20:23 <pave1> Agreed it is right workaround but Greg did not react to followup mail.
12:20:59 <pave1> We should just take msleep -> mdelay into cip.
12:21:30 <pave1> And let mainline / stable figure out better fix once
12:21:40 <pave1> our boards are booting.
12:22:27 <iwamatsu> OK, agree.
12:22:36 <jki> perfect
12:22:48 <patersonc> Thanks
12:22:56 <cbeznea_> thanks!
12:23:21 <iwamatsu> Now, let's apply  the mdelay patch to fix the problem.
12:23:48 <jki> https://lore.kernel.org/netdev/agRhFtawP06hWyRa@v4bel/ - more frag stuff, unclear if exploitable at this point
12:24:51 <jki> let's cross fingers that we won't have to switch to weekly releases...
12:24:59 <jki> ...or even more
12:25:20 <pave1> At some point we'll declare
12:25:45 <pave1> that local exploits can wait....
12:26:27 <pave1> But hopefully this should fly over in month or so.
12:27:15 <jki> the patterns may repeat: find a new vul-class, start AI, find lots of instances in short time, with exploits
12:27:28 <pave1> Yep.
12:27:49 <jki> so, move on?
12:28:07 <jki> 5
12:28:09 <jki> 4
12:28:11 <jki> 3
12:28:12 <jki> 2
12:28:14 <jki> 1
12:28:16 <jki> #topic Kernel release status
12:28:26 <jki> all fine, but we know, why...
12:28:35 <jki> anything to add?
12:28:57 <jki> 5
12:28:59 <jki> 4
12:29:01 <jki> 3
12:29:02 <jki> 2
12:29:04 <jki> 1
12:29:06 <jki> #topic Kernel testing
12:29:18 <arisut> nothing to add
12:29:41 <patersonc> We now have stable-rc testing for 7.0.y
12:30:17 <pave1> That was today?
12:30:57 <patersonc> Yes
12:31:09 <pave1> Aha, good, thanks!
12:32:59 <jki> more on testing?
12:33:11 <patersonc> Not from me
12:33:28 <jki> 5
12:33:30 <jki> 4
12:33:32 <jki> 3
12:33:34 <jki> 2
12:33:36 <jki> 1
12:33:38 <jki> #topic AOB
12:34:38 <jki> further topics for today?
12:35:10 <jki> if not...
12:35:12 <jki> 5
12:35:14 <jki> 4
12:35:16 <jki> 3
12:35:17 <jki> 2
12:35:19 <jki> 1
12:35:21 <jki> #endmeeting