Bug#867486: Issue with the audit subsystem
Le 03/08/17 à 07:46, Salvatore Bonaccorso a écrit :
Hi Laurent,
Hi,
Sorry for the lack of time and no reply to this.
On Fri, Jul 14, 2017 at 02:40:02PM +0200, Laurent Bigonville wrote:
Le 09/07/17 à 21:58, Salvatore Bonaccorso a écrit :
Hi
Hi,
Unconfirmed, but the behaviour you are seen might be related to the
changes which went in in 4.11 around
264d509637d95f9404e52ced5003ad352e0f6a26 .
https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26
I posted on the linux-audit mailing list and I get the following reply from
Paul Moore:
On Mon, Jul 10, 2017 at 10:59 AM, Laurent Bigonville wrote:
Hi,
With 4.11.6 (that has been uploaded in debian unstable) I get a lot of
messages in dmesg like
[100052.120468] audit: audit_lost=66041 audit_rate_limit=0
audit_backlog_limit=8192
[100052.120470] audit: kauditd hold queue overflow
And it also seems that the messages are not stored in auditd logs anymore.
https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26 seems
to be included in this release
An idea?
I'm going to assume that your backlog limit is set to a sane value for
your system's configuration, so that leaves me with two commits that
may be of interest:
* 1df30f8264b8 ("audit: fix the RCU locking for the auditd_connection
structure")
This was a manual backport of a v4.12 patch to v4.11, looking now, I
see it should be in +v4.11.5 so that probably isn't your problem ...
* c81be52a3ac0 ("audit: fix a race condition with the auditd tracking code")
This patch is relatively new and was just sent up to Linus during the
next merge window; it's a race condition fix so reproducing it can be
tricky, although it may be easily reproducible on your system at the
moment (luck you!). If you aren't in a position to apply the patch,
the workaround is rather simple: restart auditd.
If none of the above works, let me know, but I strongly suspect you're
tripping over the race condition fixed in that last patch.
I still should test the last patch he mentioned
Did you manage to test the last patch he mentioned? And does it
resolve the issue?
I didn't had the time to recompile the kernel with that patch included.
I can just confirm that it still happening with the kernel currently in
experimental (4.12.2-1~exp1)
Bug#867486: Issue with the audit subsystem
Hi Laurent,
Sorry for the lack of time and no reply to this.
On Fri, Jul 14, 2017 at 02:40:02PM +0200, Laurent Bigonville wrote:
> Le 09/07/17 à 21:58, Salvatore Bonaccorso a écrit :
> > Hi
> Hi,
>
> > Unconfirmed, but the behaviour you are seen might be related to the
> > changes which went in in 4.11 around
> > 264d509637d95f9404e52ced5003ad352e0f6a26 .
> >
> > https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26
> >
>
> I posted on the linux-audit mailing list and I get the following reply from
> Paul Moore:
>
> > On Mon, Jul 10, 2017 at 10:59 AM, Laurent Bigonville
> > wrote:
> > > Hi,
> > >
> > > With 4.11.6 (that has been uploaded in debian unstable) I get a lot of
> > > messages in dmesg like
> > >
> > > [100052.120468] audit: audit_lost=66041 audit_rate_limit=0
> > > audit_backlog_limit=8192
> > > [100052.120470] audit: kauditd hold queue overflow
> > >
> > > And it also seems that the messages are not stored in auditd logs anymore.
> > >
> > > https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26
> > > seems
> > > to be included in this release
> > >
> > > An idea?
> > I'm going to assume that your backlog limit is set to a sane value for
> > your system's configuration, so that leaves me with two commits that
> > may be of interest:
> >
> > * 1df30f8264b8 ("audit: fix the RCU locking for the auditd_connection
> > structure")
> >
> > This was a manual backport of a v4.12 patch to v4.11, looking now, I
> > see it should be in +v4.11.5 so that probably isn't your problem ...
> >
> > * c81be52a3ac0 ("audit: fix a race condition with the auditd tracking code")
> >
> > This patch is relatively new and was just sent up to Linus during the
> > next merge window; it's a race condition fix so reproducing it can be
> > tricky, although it may be easily reproducible on your system at the
> > moment (luck you!). If you aren't in a position to apply the patch,
> > the workaround is rather simple: restart auditd.
> >
> > If none of the above works, let me know, but I strongly suspect you're
> > tripping over the race condition fixed in that last patch.
>
> I still should test the last patch he mentioned
Did you manage to test the last patch he mentioned? And does it
resolve the issue?
Regards,
Salvatore
Bug#867486: Issue with the audit subsystem
Le 09/07/17 à 21:58, Salvatore Bonaccorso a écrit :
Hi
Hi,
Unconfirmed, but the behaviour you are seen might be related to the
changes which went in in 4.11 around
264d509637d95f9404e52ced5003ad352e0f6a26 .
https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26
I posted on the linux-audit mailing list and I get the following reply
from Paul Moore:
On Mon, Jul 10, 2017 at 10:59 AM, Laurent Bigonville wrote:
Hi,
With 4.11.6 (that has been uploaded in debian unstable) I get a lot of
messages in dmesg like
[100052.120468] audit: audit_lost=66041 audit_rate_limit=0
audit_backlog_limit=8192
[100052.120470] audit: kauditd hold queue overflow
And it also seems that the messages are not stored in auditd logs anymore.
https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26 seems
to be included in this release
An idea?
I'm going to assume that your backlog limit is set to a sane value for
your system's configuration, so that leaves me with two commits that
may be of interest:
* 1df30f8264b8 ("audit: fix the RCU locking for the auditd_connection
structure")
This was a manual backport of a v4.12 patch to v4.11, looking now, I
see it should be in +v4.11.5 so that probably isn't your problem ...
* c81be52a3ac0 ("audit: fix a race condition with the auditd tracking code")
This patch is relatively new and was just sent up to Linus during the
next merge window; it's a race condition fix so reproducing it can be
tricky, although it may be easily reproducible on your system at the
moment (luck you!). If you aren't in a position to apply the patch,
the workaround is rather simple: restart auditd.
If none of the above works, let me know, but I strongly suspect you're
tripping over the race condition fixed in that last patch.
I still should test the last patch he mentioned
Bug#867486: Issue with the audit subsystem
Hi Unconfirmed, but the behaviour you are seen might be related to the changes which went in in 4.11 around 264d509637d95f9404e52ced5003ad352e0f6a26 . https://git.kernel.org/linus/264d509637d95f9404e52ced5003ad352e0f6a26 Regards, Salvatore
Bug#867486: Issue with the audit subsystem
Package: src:linux Version: 4.11.6-1 Severity: important Hi, Starting with 4.11 I get issues with the audit subsystem. Most of the audit trails are not logged in auditd but in dmesg and I also see a lot of warnings/erros in there: [34078.975005] audit: audit_lost=117558 audit_rate_limit=0 audit_backlog_limit=8192 [34078.975005] audit: kauditd hold queue overflow This is annoying Regards, Laurent Bigonville -- Package-specific info: ** Version: Linux version 4.11.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.11.6-1 (2017-06-19) ** Command line: BOOT_IMAGE=/vmlinuz-4.11.0-1-amd64 root=/dev/mapper/valinor--vg-root ro quiet splash audit=1 selinux=1 security=selinux ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: LENOVO product_name: 20CK0002MB product_version: ThinkPad T550 chassis_vendor: LENOVO chassis_version: None bios_vendor: LENOVO bios_version: N11ET41W (1.17 ) board_vendor: LENOVO board_name: 20CK0002MB board_version: SDK0E50510 WIN ** Loaded modules: ctr ccm usb_serial_simple usbserial dm_snapshot dm_bufio vhost_net vhost tap fuse rfcomm xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 xfrm_user xfrm_algo xt_addrtype tun br_netfilter overlay nf_conntrack_netbios_ns nf_conntrack_broadcast xt_tcpudp xt_CT ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 ipt_REJECT nf_reject_ipv4 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_raw ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter cmac bnep binfmt_misc nls_ascii nls_cp437 vfat fat iTCO_wdt iTCO_vendor_support arc4 intel_rapl x86_pkg_temp_thermal intel_powerclamp efi_pstore kvm_intel kvm irqbypass intel_cstate iwlmvm intel_uncore intel_rapl_perf mac80211 joydev uvcvideo videobuf2_vmalloc cdc_mbim serio_raw pcspkr efivars cdc_wdm videobuf2_memops videobuf2_v4l2 cdc_ncm cdc_acm videobuf2_core intel_pch_thermal usbnet videodev mii media iwlwifi sg btusb btrtl rtsx_pci_ms btbcm snd_hda_codec_realtek btintel snd_hda_codec_hdmi snd_hda_codec_generic memstick lpc_ich bluetooth cfg80211 snd_hda_intel thinkpad_acpi snd_hda_codec snd_hda_core snd_hwdep nvram rfkill battery snd_pcm snd_timer snd ac mei_me soundcore mei shpchp evdev coretemp parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb mbcache btrfs algif_skcipher af_alg dm_crypt dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod sd_mod hid_generic usbhid hid crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc rtsx_pci_sdmmc mmc_core aesni_intel aes_x86_64 crypto_simd glue_helper cryptd ahci libahci psmouse libata scsi_mod i2c_i801 rtsx_pci mfd_core i915 i2c_algo_bit xhci_pci drm_kms_helper ehci_pci xhci_hcd ehci_hcd e1000e ptp usbcore pps_core drm usb_common thermal wmi video button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI [8086:1604] (rev 09) Subsystem: Lenovo Broadwell-U Host Bridge -OPI [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: bdw_uncore 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 [8086:1616] (rev 09) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 5500 [17aa:2223] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller [8086:160c] (rev 09) Subsystem: Lenovo Broadwell-U Audio Controller [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller [17aa:2223] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller [0780]: I
