Your message dated Sat, 7 Jan 2017 07:41:18 +0100
with message-id <20170107064118.zjhqzuvysb3444xj@eldamar.local>
and subject line Re: Bug#850491: slurm-llnl: CVE-2016-10030
has caused the Debian Bug report #850491,
regarding slurm-llnl: CVE-2016-10030
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
850491: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850491
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: slurm-llnl
Version: 14.03.9-5
Severity: grave
Tags: upstream patch security fixed-upstream
Justification: user security hole
Hi,
the following vulnerability was published for slurm-llnl.
CVE-2016-10030[0]:
| The _prolog_error function in slurmd/req.c in Slurm before 15.08.13,
| 16.x before 16.05.7, and 17.x before 17.02.0-pre4 has a vulnerability
| in how the slurmd daemon informs users of a Prolog failure on a compute
| node. That vulnerability could allow a user to assume control of an
| arbitrary file on the system. Any exploitation of this is dependent on
| the user being able to cause or anticipate the failure (non-zero return
| code) of a Prolog script that their job would run on. This issue
| affects all Slurm versions from 0.6.0 (September 2005) to present.
| Workarounds to prevent exploitation of this are to either disable your
| Prolog script, or modify it such that it always returns 0 ("success")
| and adjust it to set the node as down using scontrol instead of relying
| on the slurmd to handle that automatically. If you do not have a Prolog
| set you are unaffected by this issue.
I'm not to familiar with slurm, but looking at the description and
code this should be the case. It is fixed upstream.
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2016-10030
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10030
[1] https://www.schedmd.com/news.php?id=178
[2]
https://github.com/SchedMD/slurm/commit/92362a92fffe60187df61f99ab11c249d44120ee
Please adjust the affected versions in the BTS as needed.
Regards,
Salvatore
--- End Message ---
--- Begin Message ---
Source: slurm-llnl
Source-Version: 16.05.8-1
On Sat, Jan 07, 2017 at 07:34:45AM +0100, Salvatore Bonaccorso wrote:
> Source: slurm-llnl
> Version: 14.03.9-5
> Severity: grave
> Tags: upstream patch security fixed-upstream
> Justification: user security hole
>
> Hi,
>
> the following vulnerability was published for slurm-llnl.
>
> CVE-2016-10030[0]:
> | The _prolog_error function in slurmd/req.c in Slurm before 15.08.13,
> | 16.x before 16.05.7, and 17.x before 17.02.0-pre4 has a vulnerability
> | in how the slurmd daemon informs users of a Prolog failure on a compute
> | node. That vulnerability could allow a user to assume control of an
> | arbitrary file on the system. Any exploitation of this is dependent on
> | the user being able to cause or anticipate the failure (non-zero return
> | code) of a Prolog script that their job would run on. This issue
> | affects all Slurm versions from 0.6.0 (September 2005) to present.
> | Workarounds to prevent exploitation of this are to either disable your
> | Prolog script, or modify it such that it always returns 0 ("success")
> | and adjust it to set the node as down using scontrol instead of relying
> | on the slurmd to handle that automatically. If you do not have a Prolog
> | set you are unaffected by this issue.
>
> I'm not to familiar with slurm, but looking at the description and
> code this should be the case. It is fixed upstream.
And now included with the recent upload of some hours ago to unstable.
So closing with that version.
Regards,
Salvatore
--- End Message ---