Admin console not accessable after 15-1 update

[brinka123]

if I compare kernel 3.13.6 with 3..9.5 then the changes described here http://cxsecurity.com/issue/WLB-2014010055

inet: prevent leakage of uninitialized memory to user in recv syscalls
Only update *addr_len when we actually fill in sockaddr, otherwise we
can return uninitialized memory from the stack to the caller in the
recvfrom, recvmmsg and recvmsg syscalls. Drop the the (addr_len == NULL)
checks because we only get called with a valid addr_len pointer either
from sock_common_recvmsg or inet_recvmsg.

as I understand this this might cause an oops error

The changes described here seem to be present in the 3.13.6 kernel but not in the 3.9.5 kernel
Thats logical because the changes describe there are 3.12.6 just copying those to 3.9.5 is not straight forward. :scratch

And using the complete new kernel is to risky?

[fvdw]

no it isn't risky only it can be quite some work to add the code we need to get support for all devices.
I will try this weekend some changes in the 3.9.5 kernel based on the patch for 3.12

and how is 2.6.39.4 doing ?

[fvdw]

I patched the 3.9.5 kernel unfortunate it doesn't solve the problem :dry

this are again the last lines in the log

Code: Select all

Sat Mar 22 18:21:58 2014   3054453856   DEBUG   Starting Thread (Thread.cpp:182:Start)
Sat Mar 22 18:21:58 2014   3054453856   DEBUG   fvdw ok create thread (Thread.cpp:209:Start)

think the focus should be now at further tracing were the instruction is that causes the oops

I also tried to debug nzbget with gdb but it mentions that at the address and offset of memcpy fault there is is source code to be displayed (maybe logical if it is a kernel function call)

[brinka123]

I am still running the test now. (more than 2 days now)..

It looks like the #166 kernel with nzbget 12.0 is stable. I pretty stressed it.

How can I help you?

I can code review, program and test.

Just to confirm that I am wrong, can you print a debug print in nzbget when the malloc returns a NULL in the DownloadHeaders functions?

Where do you get the kernel(s) code from?

The m_attr is destoyed after the thread is created. Is the data copied using memcpy in the rhread creatio call?

Looks like the unlock is not reached and the thread stops at his lock.
Regards.

[brinka123]

Still running with #166, Doesn't break. What I also feel is that this kernel is faster.
Web interface is also more responsive during heavy diskload...
With smbd 40% CPU usage, the nzbget and admin-console user interface respond just like normal.

Quickpar repair reaches 350 MB/s.

[fvdw]

yes I also have the impression that the 3.x series of the kernel is somewhat slower

How can I help you?
I can code review, program and test.

You could adapt the nzbget code and sent me that, c++ is not quite my expert knowledge, most of theime I work with C.

Just to confirm that I am wrong, can you print a debug print in nzbget when the malloc returns a NULL in the DownloadHeaders functions?

In which xxx.cpp file you want to make these changes ?

Where do you get the kernel(s) code from?

There coming form this source https://www.kernel.org/

The m_attr is destroyed after the thread is created. Is the data copied using memcpy in the rhread creatio call?
Looks like the unlock is not reached and the thread stops at his lock.

Need to look if that is the case. However it seems to fail after that call. The most logical memcpy is the on in ReadLine function in Connections.cpp

Code: Select all

      memcpy(pBufPtr, szBufPtr, len); 

I will include some debug calls before and after
ps if 2.6.39.4 runs stable without the oops then we can conclude that it must be a kernel problem

[fvdw]

funny I put in some debu lines in that routine before and after memcpy and it produces quite some output..but it refuses to crash now, already running for more then 1 hour within combination with heavy samba load. Normally it crashes then within 10 minutes.

nzbget-12-0-extradebug-23mar14.zip

the log is now full with this fvdw realine 1 is at start of realine function, realine 2 is just before memcpy call realine 4 just after memcpy in that function

Code: Select all

Sun Mar 23 18:22:07 2014   3062756448   DEBUG   Creating Thread (Thread.cpp:159:Thread)
Sun Mar 23 18:22:07 2014   3062756448   DEBUG   Starting Thread (Thread.cpp:182:Start)
Sun Mar 23 18:22:07 2014   3062756448   DEBUG   fvdw ok create thread (Thread.cpp:209:Start)
Sun Mar 23 18:22:07 2014   3062756448   DEBUG   Accepting connection (Connection.cpp:454:Accept)
Sun Mar 23 18:22:07 2014   3008361568   DEBUG   Entering Thread-func (Thread.cpp:254:thread_handler)
Sun Mar 23 18:22:07 2014   3008361568   DEBUG   Receiving data (full buffer) (Connection.cpp:494:Recv)
Sun Mar 23 18:22:07 2014   3008361568   DEBUG   fvdw Readline 1 (Connection.cpp:376:ReadLine)
Sun Mar 23 18:22:07 2014   3008361568   DEBUG   fvdw realine 2 (Connection.cpp:420:ReadLine)
Sun Mar 23 18:22:07 2014   3008361568   DEBUG   fvdw realine 4 (Connection.cpp:422:ReadLine)

ps with this one the log file will grow fast...


Maybe we have a timing issues here. I also might replace memcpy on that location in memmove tot avoid problems if the arrays to be copied overlap

[fvdw]

it seems not possible to crash it, now I run a version with the additional debug message disabled. I put a usleep(100) command in that routine and changed memcpy in memmove. It (nzbget) is running right now with high samba load and downloading a file for 15 minutes. If it continues for another hour I will post it so you can test it as well

[brinka123]

I would first try this:

Code: Select all

WebDownloader::EStatus WebDownloader::DownloadHeaders()
{
   EStatus Status = adRunning;

   m_bConfirmedLength = false;
   const int LineBufSize = 1024*10;
   char* szLineBuf = (char*)malloc(LineBufSize);
   m_iContentLen = -1;
   bool bFirstLine = true;
   m_bGZip = false;
   m_bRedirecting = false;
   m_bRedirected = false;


      if (szLineBuf == NULL)
      {
             debug("fvdw Malloc failed in DownloadHeaders");
            satus = adFailed;
            break;
      }


Code: Select all

WebDownloader::EStatus WebDownloader::DownloadBody()
{
   EStatus Status = adRunning;

   m_pOutFile = NULL;
   bool bEnd = false;
   const int LineBufSize = 1024*10;
    char* szLineBuf =  (char*)malloc(LineBufSize);

      if (szLineBuf==NULL)
      {
          debug("fvdw Malloc failed in DownloadBody");
            satus = adFailed;
            break;

      }


Due to print statements, task scheduling changes...

Didn't manage to setup the c++ compiler. How did you installed it. apt-get doesnt work....

[fvdw]

it is still running with the change to memmove and adding the usleep9100). Heavy loading with samba in parallel doesn't affect it until now.
I attached the version that is currently running

nzbget-12-0-memove-23mar14.zip

I also incorporate your changes also, which needed to be adapted a little
You wrote satus instead of Status and you can not use a "break" outside a while loop switch statement
This is the right code to use

Code: Select all

if (szLineBuf == NULL)
       {
            warn("fvdw Malloc failed in DownloadHeaders", m_szInfoName);
            Status = adFailed;
            free(szLineBuf);
           return Status;           
      }


Code: Select all

     if (szLineBuf==NULL)
      {
          warn("fvdw Malloc failed in DownloadBody", m_szInfoName);
            Status = adFailed;
            free(szLineBuf);
           return Status; 
      }


I also added the nzbget compiled with this code incorporated (not tested)

nzbget-12-0-memmove-brinka-changes-23mar14.zip

Setting up the compiler is not that easy to explain, for various reason I do not publish the compiler for the moment.