Re: [Evergreen] new kernel for 11.4
On Fri, Nov 04, 2016 at 06:14:49PM +0100, Simon Becherer wrote: > > i am surprised, today i recogniced that you have a kernel > update for 11.4? is this correct? > from 3.0.101-102.1 to 3.0.101-105.1 It was supposed to be just an update fixing recent serious vulnerability known as "Dirty Cow" (CVE-2016-5195, bsc#1004418) but then I realized I forgot to actually submit the previous kernel update in May. That's why the changelog diff looks rather strange. Anyway, 11.4 is definitely missing lot of other important security fixes so anyone still running it somewhere is strongly advised to upgrade (Leap 42.2 seems to be the most reasonable choice at the moment, at least for servers). Michal Kubeček ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] AppArmor change_hat failures with kernel 3.12
On Tue, Aug 30, 2016 at 11:32:38PM +0200, Christian Boltz wrote:
> Michal, do you know if there were AppArmor-related patches added between
> the previous 3.11 Evergreen kernel and the (AFAIK) SLE-based 3.12 kernel
> that could explain this problem?
In general, Evergreen 13.1 kernel is mostly the same as SLE12-SP1. There
are some differences but those are mostly fixes needed to build of
architectures and drivers/features not built in SLE (none of them is
AppArmor related, IIRC). And, of course, the configs are quite different
but the AppArmor related options seem to be the same.
As for the AppArmor related changes, there are 20 mainline commits
between 3.11 and 3.12:
ed2c7da3a40c apparmor: fix bad lock balance when introspecting policy
5cb3e91ebd04 apparmor: fix memleak of the profile hash
4cd4fc77032d apparmor: fix suspicious RCU usage warning in
policy.c/policy.h
71ac7f6255c5 apparmor: Use shash crypto API interface for profile hashes
5265fc6219dd module/lsm: Have apparmor module parameters work with no
args
f8eb8a1324e8 apparmor: add the ability to report a sha1 hash of loaded
policy
84f1f787421c apparmor: export set of capabilities supported by the
apparmor module
29b3822f1e13 apparmor: add the profile introspection file to interface
556d0be74b19 apparmor: add an optional profile attachment string for
profiles
0d259f043f5f apparmor: add interface files for profiles and namespaces
038165070aa5 apparmor: allow setting any profile into the unconfined
state
8651e1d6572b apparmor: make free_profile available outside of policy.c
742058b0f3a2 apparmor: rework namespace free path
fa2ac468db51 apparmor: update how unconfined is handled
77b071b34045 apparmor: change how profile replacement update is done
01e2b670aa89 apparmor: convert profile lists to RCU based locking
dd51c8485763 apparmor: provide base for multiple profiles to be replaced
at once
9d910a3bc010 apparmor: add a features/policy dir to interface
c611616cd3cb apparmor: enable users to query whether apparmor is enabled
dfe4ac28be73 apparmor: remove minimum size check for vmalloc()
and 3.12.41 backport of mainline commit 39f1f78d53b9 ("nick kvfree()
from apparmor"). Then there and SLE specific patches
patches.apparmor/apparmor-allow-sys_cap_resource-to-be-sufficient-to-prlimit-another-task
patches.apparmor/apparmor-temporary-work-around-for-bug-while-unloadi
patches.fixes/apparmor-fix-open-after-profile-replacement.patch
patches.fixes/apparmor-fix-replacement-not-being-applied.patch
patches.fixes/skip-proc-ns-files.patch
(also one which has already been in 3.11 based 13.1 kernel and has been
refreshed). Unfortunately none of these has usable mainline refernce.
Finally, I found one patch which was in the 3.11 kernel but is missing
in SLE12-SP1 and evergreen-13.1:
patches.apparmor/apparmor-profiles-seq_file
but this seems to be obsoleted by mainline commit 29b3822f1e13.
You can find SLE12-SP1 sources at
http://kernel.suse.com/branches/SLE12-SP1
I'm not mirroring evergreen 13.1 kernel sources to a public location at
the moment but if there is interest, I can push them to github.
Michal Kubecek
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Q: os13.1 with kernel 3.12
On Wednesday, 24 August 2016 20:28 Achim Klausmann (V) wrote: > Hello, > > is there back-ported Code from kernel 4.x in the evergreen kernel > 3.12? Is that memory related? There is quite a lot of backports from 4.x mainline in Evergreen 13.1 kernel (1802 patches at the moment). Some of those are memory management related or affect its code. > I'm running openSUSE 13.1 with an Oracle Database Express Edition 11 > on several machines. > After updating from kernel 3.11 to kernel 3.12 via 'zypper up' > we got some problems in different database functions. > > It's the same like having leap 42.1 with kernel 4.x > or Oracle Linux with UEK4 (kernel 4.x) I'm afraid not much can be done with so vague problem description. Please report a bug either against Leap 42.1 or against openSUSE 13.1 and put me into Cc. Don't forget to mention that the issues are observed on both You might also try Leap 42.2 kernel (4.4, based on SLE12 SP2). Michal Kubeček ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Patch for p7zip (CVE-2016-2335)
On Wed, Jul 20, 2016 at 08:53:36AM +0200, Bruno Friedmann wrote: > On mardi, 19 juillet 2016 22.24:46 h CEST Christian wrote: > > Am 19.07.2016 um 19:24 schrieb Bruno Friedmann: > > > On mardi, 19 juillet 2016 13.53:18 h CEST Till Dörges wrote: > > > > > > I guess it will be mandatory to open a new bug (security) topic and > > > point the one used for 13.2 > > > > Why opening a new BUG. Is the BUG boo#979823 used for 13.2 not good > > enough to be used with 13.1 ? > > > > You can always try but the bug is closed, so trying to explain why reopening > add 13.1, etc will consume almost same energy than a new bug. > > Personnally I would use a new bug procedure dedicated for evergreen. There is no need to open a new bug. Just create a maintenance request as described in section "Packager information" of https://en.opensuse.org/openSUSE:Evergreen and refer to bsc#979823 in the changelog. Michal Kubeček ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
[Evergreen] FYI: USB storage (UAS) problems with 3.12 kernels on openSUSE 13.1
Hello,
some 13.1 users encountered problems with their USB storage devices that
worked fine with 3.11 kernels but fail with recent 3.12 (Evergreen)
kernel updates. As this has been already reported twice (bsc#971330,
bsc#973663) and potential third report (bsc#978517) waits for
confirmation, I wrote a short summary of the situation.
This seems to be a generic problem of devices supporting the UAS (USB
attached SCSI) protocol which is designed to replace the older USB mass
storage Bulk Only Transfer (BOT). Devices supporting UAS are mostly
"big" (as in hundreds of gigabytes) external disks.
As there used to be a lot of problems with buggy UAS devices, their
firmware and drivers, openSUSE 13.1 blacklists uas driver by adding line
"blacklist uas" to /etc/modprobe.d/50-blacklist.conf so that regular
usb-storage driver is used instead.
However, the 3.12 kernel comes from SLE12-SP1 which does not have this
general blacklist of uas driver and (at least) some UAS require uas
driver to work unless explicitely told otherwise. There are two ways to
resolve the issue:
1. (prefered) Disable the "blacklist uas" statement by commenting out
the line in /etc/modprobe.d/50-blacklist.conf (insert "#" at the
beginning). As the driver might be needed as early as in the initial
ramdisk, after editing the file, run "mkinitrd -f" and reboot.
2. Keep uas blacklisted and allow usb-storage to be used for your UAS
capable device. This can be achieved by adding line like
options usb-storage quirks=0x:0x:u
with and replaced by USB vendor and product id of your device
(these can be found in lsusb output on system where the device works) to
file /etc/modprobe.d/99-local.conf Again, run "mkinitrd -f" and reboot.
There is also the option of providing sysconfig package update disabling
the blacklist line but I'm a bit afraid this might break things for
people with devices where the support is still buggy (as openSUSE is
exposed to much wider range of defices than SLE). Another option would
be patching the Evergreen 13.1 kernel to allow using usb-storage for all
UAS capable devices without requiring the per-device quirks. I'm not
sure how much risk this would be.
Michal Kubecek
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Where's the last 3.12 kernel update for 13.1
On Wed, Apr 27, 2016 at 02:19:12AM +0200, Ruediger Meier wrote: > > BTW one thing I was always wondering about. What is the most simple > way to install such non-offcial patch without adding that Maintenance > repo. Do we have something like > > zypper patch -r > http://download.opensuse.org/repositories/openSUSE:/Maintenance:/4966/openSUSE_13.1_Update/ I don't think so, the power of libzypp is efficient work with processed metadata using the satsolver. So even if such feature existed, it would still have to do about the same as zypper ar -f ... tmp zypper patch -r tmp zypper rr tmp If you do this often, you can write a script. Michal Kubecek ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Where's the last 3.12 kernel update for 13.1
On Fri, Apr 22, 2016 at 08:51:06AM +0200, Bruno Friedmann wrote:
> Stangely on mirrors and download.o.o in update/13.1 there's no more
> kernel 3.12
> The metadata were created April 20th.
>
> Someone has an idea of what happenned ?
It might be somehow related to the fact that I submitted another update
this week - even if I have no idea how or why and I'm pretty sure it's
not supposed to work that way.
Michal Kubecek
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] samba security update - badlock and friends
On Sat, Apr 16, 2016 at 12:24:03AM +0200, Christian Boltz wrote: > > The samba update is submitted now to > > openSUSE:Evergreen:Maintenance:4627 If you are going to submit the > > AppArmor profile update, using this incident would be IMHO the best > > option as that way both samba and profile update would be released at > > once, preventing regressions. > > What is the best way to do this? > I'd guess something like > > osc sr security:apparmor apparmor_2_8 \ > openSUSE:Evergreen:Maintenance:4627 WHATEVER > > but I'm not sure what I should use for WHATEVER ;-) I assume apparmor.openSUSE_13.1_Update Or maybe rather osc mr -a Evergreen:MaintenanceProject \ --incident-project openSUSE:Evergreen:Maintenance:4627 \ security:apparmor apparmor_2_8 openSUSE:13.1:Update But I'm not realy expert on this. So maybe > That said - I don't think having a separate update is a real problem if > both are released at the same time (or AppArmor first). might be the safest option after all. > [1] 2.10 isn't the worst thing that can happen to you ;-) and probably > has much less bugs than 2.8.4 - but I understand that such a version > update isn't the best idea for a maintenance release. > I'll ignore the fact that we do a version update of Samba ;-) I'm really not happy about it either. I even tried to start rebasing the series but after more than half of first 10 commits needed adjusting and there were still more than 200 more, I realized that upgrade is probably the only viable option. After all, the fact that the same was done in SLE12 GA was a hint... Michal Kubecek ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] samba security update - badlock and friends
On Thu, Apr 14, 2016 at 07:25:51AM +0200, Michal Kubecek wrote:
> On Thu, Apr 14, 2016 at 12:31:48AM +0200, Christian Boltz wrote:
>
> > General feedback if we want that "big" profile update patch or only a
> > "small" patch to adjust the samba/nmbd profile is also welcome.
>
> As you seem to know that some of the changes are actually needed in 13.1
> (and IIRC you mentioned one in the recent nscd thread), I would vote for
> the full patch.
The samba update is submitted now to openSUSE:Evergreen:Maintenance:4627
If you are going to submit the AppArmor profile update, using this
incident would be IMHO the best option as that way both samba and
profile update would be released at once, preventing regressions.
Michal Kubecek
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] BUG: errors with samba at 100% CPU after kernel update
On Thu, Mar 31, 2016 at 09:07:10AM +0200, Georg Weickelt wrote:
>
> After updating the kernel to 3.12.53-40-default samba is no longer
> running smoothly. The smbd process often stands at 100% CPU and can
> not be removed by kill.
Contents of /proc/$pid/stack (where $pid is PID of the process) could be
helpful.
> From time to time am message like this
> appears:
> BUG: Sooft lockup CPU#0 stuck for 22s smbd-notifyd
When this happens, full kernel log could help with investigating the
issue.
Please use bugzilla for reporting bugs. Assign the bug to me
(mkube...@suse.com) or add me to Cc.
Michal Kubecek
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] 13.1 kernel update to 3.12 (SLES 12 SP1 level) ready for test
On Mon, Mar 07, 2016 at 02:20:36PM +0100, Marcus Meissner wrote:
>
> negative points were:
> NVIDIA - That "hard way" is needed is to be expected.
Yes, any third party module needs to be rebuilt. On the other hand, once
it is built for the 3.12 kernel, there should be no need for further
rebuilds on future updates.
> aacraid - Not many people use it and it did not clearly turn out to be
> a regression.
I'm going to ask SCSI guys for an opinion; what is confusing is the
driver is the same as in SLE12-SP1 and almost the same as in mainline
4.4 kernel. It might be something trivial - and it might also be a bug
affecting SLE12-SP1.
There is also bsc#966831 but that is not a regression either. It's going
to be fixed with next update.
> Otherwise it seemed all good.
>
> I just released the kernel update to 3.12.53.
Thank you.
A general note: if anybody is going to report a bug for the 3.12 kernel,
please add me to Cc (my bugzilla account is mkube...@suse.com).
Michal Kubecek
___
Evergreen mailing list
Evergreen@lists.rosenauer.org
http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Fwd: [security-announce] Todays openssl release - "DROWN" CVE-2016-0800 and "Cachebleed"
On Wed, Mar 02, 2016 at 08:06:31AM +0100, Patrick Schaaf wrote: > On Wed, Mar 2, 2016 at 7:58 AM, Michal Kubecek <m...@mk-sys.cz> wrote: > > This is surprising as current evergreen 11.4 openssl update (version > > 1.0.1p-68.2) does present exactly the same version (0x1000110f) which > > was one of the reasons why I did cherry pick CVE related fixes from > > 1.0.1 branch since 1.0.1p instead of simply upgrading to 1.0.1s. > > Thanks for the explanation. All is well (see my other mail) Mid-air collision. :-) > Just to be sure - this is what I see now with zypper -s search > regarding installed stuff: > > i | home_mkubecek_branches_Evergreen_Maintained_openssl | patch | > 1| noarch | Evergreen 11.4 Test > i | libopenssl-devel| patch | > 5761 | noarch | openSUSE 11.4 Update > i | libopenssl-devel| patch | > 5634 | noarch | openSUSE 11.4 Update > i | libopenssl-devel| patch | > 5178 | noarch | openSUSE 11.4 Update > i | libopenssl-devel| patch | > 4669 | noarch | openSUSE 11.4 Update > i | libopenssl1_0_0 | package| > 1.0.1p-71.1 | x86_64 | Evergreen 11.4 Test > i | openssl | package| > 1.0.1p-71.1 | x86_64 | Evergreen 11.4 Test > > Is that patch at the top okay? What does that do? Testing artefact? IMHO this is because I already filled in patchinfo in the project so that zypper shows also a "patch" in the search, not only packages. The way I understand it, a "patch" represents a set of packages provided within one maintenance incident (e.g. the two packages seen here or the whole set of kernel update packages). But I'm far from an expert on this topic. Anyway, I tested the update packages on two systems now (one testing virtual machine, one real server) and everything seems to work so I submitted the update (maint. request #364016). Michal ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Fwd: [security-announce] Todays openssl release - "DROWN" CVE-2016-0800 and "Cachebleed"
On Tue, Mar 01, 2016 at 07:05:24PM +0100, Wolfgang Rosenauer wrote: > > I'm not sure what to do for 11.4. 11.4 is currently on 1.0.1p and > probably it's totally acceptable to update it to 1.0.1s? > > Anyone up for taking care? I have packages ready in OBS; they passed openssl testsuite (as part of the build) but I haven't tested them on a real system yet and it's too late already so I'll have to leave that for tomorrow morning. If anyone wants to give them a try, repository location is http://download.opensuse.org/repositories/home:/mkubecek:/branches:/Evergreen_Maintained:/openssl/openSUSE_Evergreen_11.4/ Michal ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Evergreen 13.1 kernel - conclusion
On Wed, Feb 03, 2016 at 09:30:42AM +0100, Marcus Meissner wrote: > On Wed, Feb 03, 2016 at 08:28:43AM +0100, Michal Kubecek wrote: > > On Tue, Feb 02, 2016 at 10:25:10PM +0100, Michal Kubecek wrote: > > > On Tue, Feb 02, 2016 at 04:20:09PM +0100, Marcus Meissner wrote: > > > > > > > we will probably need to refresh some of the kmps too if they no > > > > longer build. > > > > > > I have all 13.1 packages which build KMPs linked in my home project but > > > only some of them needed patching; I'll submit those with kernel-source > > > (and probably also kernel-firmware) unless you tell me otherwise. > > > > Thinking about it again, I'm not sure what exactly needs to be done. > > Only three packages building KMPs need patching: > > > > ndiswrapper > > openvswitch > > pcfclock > > > > The rest, i.e. > > > > cloop > > crash > > hdjmod > > ipset > > iscsitarget > > vhba-kmp > > virtualbox > > xen > > xtables-addons > > > > build without any source change (virtualbox needed a patch originally > > but it does not since January 2015 update). However, they will still > > need a rebuild to work with new kernel which is probably not going to > > happen itself. Would submitting them anyway (without any source change) > > do the trick? Or perhaps adding an entry to *.changes (like "rebuild for > > 3.12 kernel")? > > I can and would branch the unchanged myself, no need to submit them. maintenance request #357472 created Michal Kubeček ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
Re: [Evergreen] Evergreen 13.1 kernel - conclusion
On Tue, Feb 02, 2016 at 05:37:36PM -0500, Felix Miata wrote: > Michal Kubecek composed on 2016-02-02 22:25 (UTC+0100): > > >> > Marcus Meissner wrote: > > >> > > Also a side note, we are testing a 13.1 kernel update for the current > >> > > local root exploit and will want to release that before. > > >> > OK, I'll wait until this one is released. For some reason I thought it > >> > already was out. > > >> We have released it now. > > >> http://lists.opensuse.org/opensuse-updates/2016-02/msg3.html > > >> If you submit, submit with > > >>osc mr YOURSOURCEPROJECT kernel-source openSUSE:13.1:Update > > >> (This ensures it will land in openSUSE:Maintenance and not > >> openSUSE:Evergreen:Maintenance) > > > Thanks for the info, I'll submit it tomorrow. > > >> we will probably need to refresh some of the kmps too if they no > >> longer build. > > > I have all 13.1 packages which build KMPs linked in my home project but > > only some of them needed patching; I'll submit those with kernel-source > > (and probably also kernel-firmware) unless you tell me otherwise. > > Whatever happened to the idea of using newer (3.12) for Evergreen? I've been > using those from repositories/home:/mkubecek:/evergreen-13.1/openSUSE_13.1/ > on most of my installations ever since you first announced that repo, going > on two years ago. That's exactly what we are talking about. Michal Kubeček ___ Evergreen mailing list Evergreen@lists.rosenauer.org http://lists.rosenauer.org/mailman/listinfo/evergreen
