> > > "2.1.131a" or "2.1.131aa" or "2.1.131-preX" or whatever kernel with
> > > 8 or more chars will crash the server.
> >
> > > so, if you used some -pre kernel version, this should be it.
> > > edit Makefile and remove the extraversion.
> >
> > Hmm. I think it might be a good idea to provide snprintf next to sprintf...
> > (Or even remove sprintf to make sure everyone uses the safe version)
> >
> > If any of the kernel-gods wnat this, I'll make a patch for it in the comming
> > week.
>
> I'd prefer you post a more detailed note on this to IBM security and to bugtraq.
> Its a potentially serious compromise in an important backup tool.
I verified things and it looks like Andreas is right as to the CAUSE of
the problem. We had upgraded from 2.2.12 to 2.2.13-newide-reiserfs when
the ADSM server died upon the next dsmc sched.
It looks like IBM has already addressed things, it seems however that
not everybody is aware of this. The current ADSM Solaris server software
version is 3.1.2.50, excerpt from the changelog is below.
So, posting to IBM security might be the wrong address.
See: http://www.tivoli.com/support/storage_mgt/adsm/adsercli.htm#servfix
Excerpt from (make sure the URL is on one line without blanks!)
ftp://service.boulder.ibm.com/storage/adsm/fixes/v3r1/sunsrv/
LATEST.SERVICE/IP21881.31250.README
|ADSTAR Distributed Storage Manager(ADSM) Server for Solaris 2.5.1/2.6/7
|
|[...]
|
|----------------------------------------
|APARS fixed by service level 3.1.2.30
|----------------------------------------
|
|[...]
|
|IX89544 CLIENT PLATFORM NAME PASSED TO THE SERVER IS TOO LONG,
|CAUSING THE ADSM SERVER TO CORE DUMP.
|
| ADSM client was sending a platform name that is longer than
| what ADSM server is expecting. So when using the platform
| name, ADSM server may crash due to the extra long platform
| name.
I have just phoned to the administrator of our ADSM Server, we have
agreed to check if the aforementioned update fixes our problem
beforehand. (The administrator will check if our server is live daily
and block offending nodes in case there's trouble again.)
We have agreed to not contact IBM or post to Bugtraq until the problem
is resolved for us.
Since nuking the ADSM server software requires a) a valid ADSM client
node (including password), b) a deliberately installed kernel with long
uname release reply, the adminstrators of our server rely on nobody
updating to non-mainstream-kernels until January 3rd/4th, 2000, since
the machines will run unattended until then and you don't want to update
a running system when there's nobody present who can fix problems as
they occur.
So, if anybody can reproduce the problem described herein and is
inclined to post to Bugtraq, please check if the updates to the ADSM
server help BEFORE posting to Bugtraq. IF the ADSM server updates help
with the problem (and have the server software survive even when you use
a machine with "2.2.13-my-very-special-kernel" release), a reminder to
Bugtraq might be appropriate.
Again, thanks for the pointer!
-- Matthias AndreeHi! I'm the infamous .signature virus! Copy me into your ~/.signature to help me spread!
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/