Public bug reported:
3 Ubuntu VMs using the latest kernel all show the same issue when using
an fscrypted folder on CephFS.
No problems occur when the fscrypted folder is not decrypted but after
decryption dmesg output shows what looks like a kernel oops and the
machines are partially locking up
Just had this issue on a AD2550R/U3S3 motherboard with Ubuntu 16.04.2
Server. Installation display works fine, post installation display no
longer works after a quick text scroll (doesn't get to login.)
Intel GMA 3600 GPU had no display output and wasn't fixed my nomodeset
or other GMA related fix
I will only add that even in the best of circumstances with perfect
firewalling, a low privilege sysadmin or helpdesk member/troubleshooter
could easily use this overflow as a hop to privilege escalation and/or
willful damage.
--
You received this bug notification because you are a member of Ubun
It would appear a solution to the firewall being open before shorewall
start is to use the 'shorewall-init' package.
http://shorewall.net/Shorewall-init.html
The extra init package closes the firewall prior to shorewall startup
avoiding that issue (assuming you set the product in
/etc/default/sh
On further inspection, the reload command in 4.6.4.3 is clearly not
doing what the manpage is saying on shorewall which I will put down to
not being shorewall 5.X, pre-5.X reload appears to be a reload of a
remote host which was moved to a separate command (remote-restart) in
5.X
So yes, is should
I pulled this as I said from the Deb service file, I cannot remember the
rationale behind waiting for the network to start but I remember
something to do with PPPOE connections being potentially problematic for
some reason.
I ran this past a Shorewall guru in their IRC but frankly I am not too
wor
I would not consider a buffer overflow and code execution as low
priority, especially when this program is likely to run on a firewall or
network gateway.
Is there a better timeline than when "we feel like there's a real issue"
we'll update? We are now 2 generations depreciated...
--
You receive
Public bug reported:
Upon package installation the install prompt asks for a LAN IP to listen
on, when set miniupnpd gets the IP value from /etc/default/miniupnpd it
cannot start as it expects a LAN interface.
*Tested in 15.10*
e.g. value in /etc/default/miniupnpd
MiniUPnPd_LISTENING_IP = 10.0
Can confirm this bug in 15.10, init.d script not really needed.
Correction to Poldi's workaround (didn't work for me), I pulled the
Debian service file from the Shorewall tgz which appears to be fully
functional, same as poldi, make the service file and enable it and you
are good to go:
#
# T
