https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-11173 Lustre <p>The SUSE Linux Enterprise 12 SP3 kernel was updated to 4.4.140 to receive<br/> various security and bugfixes.</p> <p>The following security bugs were fixed:</p> <ul class="alternate" type="square"> <li>CVE-2018-13053: The alarm_timer_nsleep function had an integer overflow<br/> via a large relative timeout because ktime_add_safe was not used<br/> (bnc#1099924)</li> <li>CVE-2018-9385: Prevent overread of the "driver_override" buffer<br/> (bsc#1100491)</li> <li>CVE-2018-13405: The inode_init_owner function allowed local users to<br/> create files with an unintended group ownership allowing attackers to<br/> escalate privileges by making a plain file executable and SGID<br/> (bnc#1100416)</li> <li>CVE-2018-13406: An integer overflow in the uvesafb_setcmap function<br/> could have result in local attackers being able to crash the kernel or<br/> potentially elevate privileges because kmalloc_array is not used<br/> (bnc#1100418)</li> </ul> <p>For fixed non-security bugs, please refer to:</p> <p><a href="http://lists.suse.com/pipermail/sle-security-updates/2018-July/004305.html" class="external-link" target="_blank" rel="nofollow noopener">http://lists.suse.com/pipermail/sle-security-updates/2018-July/004305.html</a></p> LU-11173

kernel update [SLES12 SP3 4.4.140-94.42.1]

Bug Minor Resolved Won't Fix Jian Yu Jian Yu Wed, 25 Jul 2018 02:50:08 +0000 Thu, 23 Aug 2018 16:30:11 +0000 Thu, 23 Aug 2018 16:30:11 +0000 0 6 <p>Jian Yu (yujian@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/32888" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/32888</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11173" title="kernel update [SLES12 SP3 4.4.140-94.42.1]" class="issue-link" data-issue-key="LU-11173"><del>LU-11173</del></a> kernel: kernel update <span class="error">&#91;SLES12 SP3 4.4.140-94.42&#93;</span><br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 3564d283d8b81b0cc7fd44cc58c0360fbf3e3008</p> <p>While applying patch blkdev_tunables-3.8-sles12.patch to SLES12 SP3 4.4.140-94.42.1, the following conflict occurred:</p> <div class="code panel" style="border-width: 1px;"><div class="codeHeader panelHeader" style="border-bottom-width: 1px;"><b>include/scsi/scsi.h.rej</b></div><div class="codeContent panelContent"> <pre class="code-java"> --- include/scsi/scsi.h +++ include/scsi/scsi.h @@ -24,7 +24,7 @@ <span class="code-keyword">enum</span> scsi_timeouts { * to SG_MAX_SINGLE_ALLOC to pack correctly at the highest order. The * minimum value is 32 */ -#define SCSI_MAX_SG_SEGMENTS 128 +#define SCSI_MAX_SG_SEGMENTS CONFIG_SCSI_MAX_SG_SEGMENTS /* * Like SCSI_MAX_SG_SEGMENTS, but <span class="code-keyword">for</span> archs that have sg chaining. This limit </pre> </div></div> <p>It turns out the definition of <tt>SCSI_MAX_SG_SEGMENTS</tt> doesn't exist in the new scsi.h. I'm investigating how to resolve the conflict.</p> <p>Can we kill those patches off? Bull showed those patches don't help for a long time for performance. See <a href="https://jira.whamcloud.com/browse/LU-20" title="patchless server kernel" class="issue-link" data-issue-key="LU-20"><del>LU-20</del></a> for details.</p> <p>Thank you for the guidance, James.</p> <p>Hi Andreas,</p> <p>On master branch, the current patch list for SLES12 SP3 is:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>raid5-mmp-unplug-dev-sles12sp3.patch dev_read_only-3.9.patch blkdev_tunables-3.9-sles12sp3.patch </pre> </div></div> <p>The raid5-mmp-unplug-dev-sles12sp3.patch is still needed because it has not been submitted upstream.<br/> The dev_read_only-3.9.patch is no longer needed because it has been replaced by "dm-flakey" module.<br/> The default_max_sectors part in blkdev_tunables-3.9-sles12sp3.patch is no longer needed, but I'm not sure about the default_max_segments part according to the following comments in <a href="https://jira.whamcloud.com/browse/LU-20" title="patchless server kernel" class="issue-link" data-issue-key="LU-20"><del>LU-20</del></a>:<br/> <a href="https://jira.whamcloud.com/browse/LU-20?focusedCommentId=78574&amp;page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-78574" class="external-link" rel="nofollow">https://jira.whamcloud.com/browse/LU-20?focusedCommentId=78574&amp;page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-78574</a></p> <p>Could you please advise if we can just remove blkdev_tunables-3.9-sles12sp3.patch? Thank you.</p> <p>Actually raid5-mmp-unplug-dev-* was submitted upstream but was rejected. See</p> <p><a href="https://www.redhat.com/archives/dm-devel/2014-November/msg00004.html" class="external-link" target="_blank" rel="nofollow noopener">https://www.redhat.com/archives/dm-devel/2014-November/msg00004.html</a></p> <p>Basically that patch needs a lot more work to do the right thing. Oh how funny. It was Neil Brown that nicked the patch <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Yes, the raid5-mmp patch didn't get accepted. While there is still a race condition with the patch applied, it is definitely much smaller than without the patch at all. </p> <p>In any case, we haven't supported Lustre+ldiskfs on MD RAID devices for a long time (the MD-RAID rebuild was too slow for very large filesystems or needed dedicated flash devices), and instead we tell people to use ZFS when they want software RAID. So in summary, I don't care a huge amount about that patch anymore.</p> <p>Note that there are a couple of other kernel patches in the RHEL7 series to improve performance and/or add functionality (mainly quota related), and a new patch incoming for the T10-PI API change. My position is that these are optional patches and people can use them if they want, but we won't accept "required" kernel patches anymore. The Lustre code has to be able to build against the the vanilla kernel, possibly with some reduced functionality, and the ldiskfs module can be built/loaded independently of the main kernel. We've started building the client+server code against the unpatched kernel, and I think that should become part of the required builds for every review patch. </p> <p>We're getting closer on the remaining major ldiskfs features being included into upstream ext4 as well, and I'd be happy if we could move that further along. The main outlier at this point is the <tt>dir_data</tt> feature, and many of the remaining ext4 patches are for performance and adding exports to the code for <tt>osd-ldiskfs</tt> to use.</p> <p>Thank you for the advice, Andreas.<br/> Do I understand correctly that for the current SLES12 SP3 patch list, we need keep the raid5-mmp patch and can remove the blkdev_tunables patch?</p> <p>After removing dev_read_only-3.9.patch, sanity test 802 (simulate readonly device) failed as follows:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>Lustre: DEBUG MARKER: mkdir -p /mnt/lustre-mds1; mount -t lustre -o rdonly_dev /dev/mapper/mds1_flakey /mnt/lustre-mds1 LDISKFS-fs (dm-3): mounted filesystem with ordered data mode. Opts: user_xattr,errors=remount-ro,no_mbcache,nodelalloc format at osd_handler.c:7368:osd_mount doesn't end in newline Lustre: lustre-MDT0000-osd: not support dev_rdonly on this device LustreError: 14283:0:(obd_config.c:559:class_setup()) setup lustre-MDT0000-osd failed (-95) LustreError: 14283:0:(obd_mount.c:202:lustre_start_simple()) lustre-MDT0000-osd setup error -95 LustreError: 14283:0:(obd_mount_server.c:1902:server_fill_super()) Unable to start osd on /dev/mapper/mds1_flakey: -95 LustreError: 14283:0:(obd_mount.c:1599:lustre_fill_super()) Unable to mount (-95) </pre> </div></div> <p>Maloo report: <a href="https://testing.whamcloud.com/test_sets/c973a2a4-a5f0-11e8-a5f2-52540065bddc" class="external-link" target="_blank" rel="nofollow noopener">https://testing.whamcloud.com/test_sets/c973a2a4-a5f0-11e8-a5f2-52540065bddc</a></p> <p>Really. We still missed a dev_read_only case <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/> That means this test fails for Ubuntu support since it doesn't have the dev_read_only patches.</p> <p>Jian Yu (yujian@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/33054" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/33054</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-11173" title="kernel update [SLES12 SP3 4.4.140-94.42.1]" class="issue-link" data-issue-key="LU-11173"><del>LU-11173</del></a> kernel: kernel update <span class="error">&#91;SLES12 SP3 4.4.140-94.42&#93;</span><br/> Project: fs/lustre-release<br/> Branch: b2_10<br/> Current Patch Set: 1<br/> Commit: a204e2d527d3b6ce588413fd422610c587a340a0</p> <p>A more newer SLES12 SP3 kernel update is being worked in <a href="https://jira.whamcloud.com/browse/LU-11255" title="kernel update [SLES12 SP3 4.4.143-94.47.1]" class="issue-link" data-issue-key="LU-11255"><del>LU-11255</del></a>. Let's close this ticket.</p> Related LU-11065 LU-11255 Development Rank 1|hzzzr3: Rank (Obsolete) 9223372036854775807 Severity