amavis virus check fails when nvidia CUDA is on the same system

[Gino]

Amavis incorrectly assumes that /usr/bin/nvcc is the "Norman virus control" executable, and attempts to use it to virus check incoming emails.

In systems with the NVIDIA CUDA compiler installed, the nvcc executable is actually the CUDA compiler, and so exits with a non-zero (exit) state every time amavis attempts to execute it on email traffic.

This behavior results in all email traffic being marked (and quarantined) by amavis as containing a virus whenever NVIDIA CUDA is installed on the same system as amavisd-new.

The increasing use of gpu acceleration for speeding up and multithreading particular server processing tasks means that in the future more servers may experience this problem as they have NVIDIA CUDA installed on them.

I believe that amavis should verify that nvcc is the Norman virus control executable prior to attempting to use it as a virus check.

A workaround for this bug on current ubuntu systems is to modify the default /etc/amavis/conf.d/15-av_scanners file and comment out the following three lines:
  ['Norman Virus Control v5 / Linux', 'nvcc',
    '-c -l:0 -s -u -temp:$TEMPBASE {}', [0,10,11], [1,2,14],
    qr/(?i).* virus in .* -> \'(.+)\'/m ],

---------------
lsb_release -rd
Description: Ubuntu 16.04 LTS
Release: 16.04

---------------
apt-cache policy amavisd-new
amavisd-new:
  Installed: 1:2.10.1-2ubuntu1
  Candidate: 1:2.10.1-2ubuntu1
  Version table:
 *** 1:2.10.1-2ubuntu1 500
        500 http://au.archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        500 http://au.archive.ubuntu.com/ubuntu xenial/main i386 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: amavisd-new 1:2.10.1-2ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-22.39-generic 4.4.8
Uname: Linux 4.4.0-22-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_modeset nvidia
ApportVersion: 2.20.1-0ubuntu2
Architecture: amd64
CurrentDesktop: GNOME
Date: Tue May 17 00:11:34 2016
PackageArchitecture: all
SourcePackage: amavisd-new
UpgradeStatus: Upgraded to xenial on 2016-04-27 (19 days ago)
modified.conffile..etc.amavis.conf.d.05-node_id: [modified]
modified.conffile..etc.amavis.conf.d.15-av_scanners: [modified]
modified.conffile..etc.amavis.conf.d.15-content_filter_mode: [modified]
modified.conffile..etc.amavis.conf.d.20-debian_defaults: [modified]
modified.conffile..etc.amavis.conf.d.50-user: [modified]
mtime.conffile..etc.amavis.conf.d.05-node_id: 2008-07-24T09:24:40
mtime.conffile..etc.amavis.conf.d.15-av_scanners: 2016-05-05T16:49:24.747435
mtime.conffile..etc.amavis.conf.d.15-content_filter_mode: 2008-07-24T09:26:06
mtime.conffile..etc.amavis.conf.d.20-debian_defaults: 2016-05-05T16:43:45.387437
mtime.conffile..etc.amavis.conf.d.50-user: 2008-07-24T09:25:35

[Christian Ehrhardt  (paelzer)]

Thank you for your report, I checked around and can confirm that the packaged nvidia-cuda-toolkit causes this conflict.

I added the disabling to the merge of amavisd-new which I prepared for Yakkety as I think it is right to disable the "out-of-archive" solution in this case.

[Christian Ehrhardt  (paelzer)]

Reported to Debian and linked bug

[Launchpad Janitor (janitor)]

This bug was fixed in the package amavisd-new - 1:2.10.1-4ubuntu1

---------------
amavisd-new (1:2.10.1-4ubuntu1) yakkety; urgency=medium

  * Merge from Debian, remaining changes:
    + Add information in README.Debian about Ubuntu specific changes
    + Ubuntu configuration changes in 21-ubuntu_defaults
      - Reduce email responses for virus/blocked mail so as not to be a
        backscatter source by default
      - Enable DKIM checking by default
    + Include policy-bank of known good domains for DKIM whitelisting
      in 40-policy_banks
    + debian/control: drop altermime and ripole to Suggests after discussions
      with the server team.
    + amavisd-new-postfix configuration for anti-spam/virus
  * Dropped changes:
    + 22-amavisd-new-postfix which was forgotten since 2.6.5-0ubuntu1.
  * Added changes:
    + fix whitespace damage in d/control at amavisd-new-postfix
    + d/etc/conf.d/15-av_scanners disabled Norman Virus Control as it conflicts
      with packaged /usr/bin/nvcc of nvidia-cuda-toolkit (LP: #1582318)

amavisd-new (1:2.10.1-4) unstable; urgency=medium

  * Fix typo in recommends.
  * Fix typo in README.Debian.
  * Use https for Vcs-GIT header.
  * Fix redirect to null. Closes: #824056.
  * Update Debian standards version to 3.9.8.

 -- Christian Ehrhardt <email address hidden> Mon, 25 Jul 2016 16:11:53 +0200

[Christian Ehrhardt  (paelzer)]

FYI - Debian merged my patch and closed the bug, Delta can be dropped on next merge

[Christian Ehrhardt  (paelzer)]

Debian lost the fix along the last uploads so I reopened the Debian bug to ensure they get the fix.

[Helge Doering (spacy)]

Just encountered this bug on a xenial lts server. Isn't it supposed to be fixed there?
If it's not should we open a SRU? It seems low risk and potentially high gain.

[Christian Ehrhardt  (paelzer)]

Hi Helge,
You are right, the issue exists there.
But IMHO the backport has as SRU to Xenial has quite some regression risk and actually low gain.
Let me outline why I think so:

Looking at people that:
1. had amavisd running without - nvidia nvcc not installed
   => Things working fine
2. had amavisd running without - nvidia nvcc installed
   => amavisd is broken by this bug, but then can be fixed with a conscious config file change
3. had amavisd running without - norman AV nvcc installed
   => Things working fine WITH norman AV

Now if we would SRU something we would:
- not help #1 being not affected
- #2 was broken, so we fix something unused (and flagging all mails can be a thing as well since https://xkcd.com/1172/)
- for those people in #3 we would break a valid working setup

It is sort of unfortunate, but at least in my limited POV the risk actually outweighs the gain in this case.
Also setting up "new" Xenial should no more be a major tasks these days with Bionic being available for quite a while now.

just my 2 cents, feel free to discuss if you think otherwise.

[Helge Doering (spacy)]

Hi Christian,
I actually agree. Mostly because of the points you raised, but maybe even on a 4th point. Most users use (and should use) a virtualized or container-ized environment, where in this case this bug also does not apply. I realized this a bit after I wrote the original comment.
I still think, any "stable" distribution should be kinda... stable :) but I will agree, that pretty much nobody should have an amavisd + cuda drivers on one station (VM or bare-metal). Maybe a few private servers, but nothing serious.

As for the new distribution; well sure it is fixed, but my question was for xenial. I do retract my opinion of a "high gain". I still consider it low risk, but without a warrant, it is probably not worth the risk.

Thanks for your reply and opinion!

Helge