2022-07-05 15:08:46 <psykose> the 3.0.5 commit has CVE-2022-2097 under both the new version and 0:
2022-07-05 15:11:50 <psykose> fixd
2022-07-05 23:49:16 <omni> !35973 !35975
2022-07-05 23:52:05 <omni> I'm with psykose, on the second one, that it's probably best to wait for an official kernel release, but wanted to mention here nonetheless
2022-07-07 17:59:30 <omni> bump and !36072 and https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.15.53
2022-07-07 18:06:06 <omni> and !35959 that could also be cherry-picked for 3.15-stable
2022-07-07 18:06:23 <omni> (includes XSA-403 patch)
2022-07-07 18:23:39 <omni> !36073
2022-07-07 18:38:47 <psykose> why are the patches for 4.14 and 4.16 while 3.14 is on 4.15? was that an unstable release by accident :p
2022-07-07 18:42:51 <omni> xsa403/xsa403-4.16-?.patch    Xen 4.16.x - Xen 4.15.x
2022-07-07 18:42:53 <omni> xsa403/xsa403-4.14-?.patch    Xen 4.14.x - Xen 4.13.x
2022-07-07 18:43:08 <omni> or did I misinterpret?
2022-07-07 18:45:30 <psykose> ah
2022-07-07 18:45:34 <omni> 4.15 and 4.16 does not differ wrt these files
2022-07-07 18:45:34 <psykose> no, just the naming
2022-07-07 18:45:40 <psykose> :)
2022-07-07 18:45:42 <psykose> neat
2022-07-12 17:17:13 <psykose> omni: looks like there's an xsa407 now :)
2022-07-12 18:19:07 <omni> FUN!
2022-07-12 18:19:13 <omni> psykose: but thanks! <3
2022-07-12 18:19:19 <psykose> <3
2022-07-12 18:19:22 <omni> and an embargoed 408
2022-07-12 18:19:51 <omni> full disclosure: in my mind the only responsible disclosure is full disclosure
2022-07-12 21:54:49 <omni> am I missing something? other than some intermediate commits to the stable branch since the most recent release tarball?
2022-07-12 21:58:33 <psykose> i bet it's the exact same thing as last time..
2022-07-12 21:59:03 <psykose> really don't understand this patch process and what they mean by 'update to tip of branch to apply patches'.. the 'tip' already has the damn patches in it
2022-07-12 22:13:34 <omni> I... eh.. I may be as tired as I've been in general lately but these patches don't seem to apply cleanly to the tip of the stable branch either...
2022-07-12 22:13:52 <omni> are we missing something from XSA-408? :p
2022-07-12 22:29:20 <omni> hmm https://xenbits.xen.org/xsa/xsa407.meta
2022-07-12 22:31:31 <omni> they're supposed to be applied to seven commits after the tip of the stable-4.16 branch?
2022-07-12 22:35:46 <psykose> fun!
2022-07-12 22:36:54 <omni> what the actual >:FFFFFF
2022-07-12 22:37:25 <omni> somewhere in between the tip of stable-4.16 and staging-4.16, from what I can tell
2022-07-13 00:14:58 <omni> !36330 !36333 !36357 !36359
2022-07-13 00:22:16 <omni> !36361
2022-07-13 09:24:15 <omni> "stable-* fast forwards into staging-* when CI is happy", so that didn't happen before the XSA-407 was released then
2022-07-13 19:35:47 <Ariadne> snyk: what is the best way to report a bug in snyk
2022-07-14 11:58:15 <ncopa> im considering enabling kexec in our kernel config, however, I'm not to happy with the current upstream approach where it is enabled by default, but can be disabled userspace (but not re-enabled afterwards) with sysctl
2022-07-14 11:58:34 <ncopa> sysctl kernel.kexec_load_disable
2022-07-14 11:59:12 <ncopa> so i'm thinking enabling it compile time in our config, but have it disabled by default, and allow enabling it via boot cmdline
2022-07-14 11:59:28 <ncopa> https://tpaste.us/nVRv
2022-07-14 11:59:57 <ncopa> meaning, kexec_load_disable=1 by default, and cannot be enabled via sysctl
2022-07-14 12:00:24 <psykose> does this allow booting with =0, using kexec, then sysctl disabling it after?
2022-07-14 12:00:27 <ncopa> to use it, you *have* to add kexec_load_disable=0 to cmdline
2022-07-14 12:00:51 <ncopa> yes
2022-07-14 12:01:00 <ncopa> i believe so
2022-07-14 12:01:05 <psykose> (distinct from kexec with =1 or unset on cmdline which would disable immediately post-exec, but specifically booting with =0 and disabling it anyway)
2022-07-14 12:01:51 <ncopa> dont follow?
2022-07-14 12:02:34 <psykose> well, simpler: machine off, boot =0 (kexec on), then just pass sysctl to disable (like you can do now already), but with this patch
2022-07-14 12:03:02 <ncopa> yes
2022-07-14 12:03:22 <psykose> sounds good to me then
2022-07-14 12:03:56 <ncopa> if you boot with kexec_load_disable=0, kexec is enabled, and you can disable it with `sysclt kernel.kexec_load_disable=1`
2022-07-14 12:04:06 <ncopa> after that kexec is permanently disabled
2022-07-14 12:04:11 <ncopa> til next reboot
2022-07-14 12:04:44 <ncopa> it needs testing
2022-07-14 12:05:23 <ncopa> im also not sure I like the _disable part, whickh means you need to disable the disable knob to enable kexec
2022-07-14 12:05:36 <ncopa> but it corresponds with the sysctl, which i think makes sense
2022-07-14 12:05:48 <ncopa> it would be alpine specific way to enable kexec though
2022-07-27 19:22:49 <sukrit007> Hello alpine security team.      Needed to follow up on https://nvd.nist.gov/vuln/detail/CVE-2022-30065 .  This issue seems to be fixed in busybox-1.35.0-r17 .  But the same is not available in 3.16 main branch (only on edge):  https://pkgs.alpinelinux.org/packages?name=busybox&branch=v3.16 .  Is there a plan to promote this to main ?
2022-07-27 19:22:50 <sukrit007> https://security.alpinelinux.org/branch/3.16-main currently is not listing busybox
2022-07-27 19:29:14 <Ariadne> well, i would hope not.  those are packages which have not been investigated yet, after all.
2022-07-27 19:30:07 <Ariadne> i'm also not sure where you conclude that 1.35.0-r17 fixes that CVE, since it was fixed in 1.35.0-r16
2022-07-27 19:31:38 <Ariadne> as can be seen on https://security.alpinelinux.org/vuln/CVE-2022-30065
2022-07-27 19:34:42 <sukrit007> That was shown in our Prisma scan,    I can ask Prisma team to update their definition.  Thanks for confirming.
2022-07-27 19:34:54 <Ariadne> anyway, 1.35.0-r16 was included in 3.16.1 release, so rebasing whatever image you are using on that will fix it
2022-07-27 19:40:24 <sukrit007> (y)
2022-07-29 17:42:30 <omni> !37029 !37030 !37031 !37032