Bug 76289 - sys_call_table is not exported - breaks AFS and God knows what else in a "stable", old version
Summary: sys_call_table is not exported - breaks AFS and God knows what else in a "sta...
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.3
Hardware: All Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Keywords: Security
Depends On:
TreeView+ depends on / blocked
Reported: 2002-10-19 10:18 UTC by deniz
Modified: 2007-04-18 16:47 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-10-19 10:18:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description deniz 2002-10-19 10:18:10 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; tr-TR; rv:1.1) Gecko/20021006

Description of problem:
I have recently upgraded 7.3 machines due to the security advisory RHSA-2002:206-12,
which necessitates upgrading the kernel from 2.4.18-10 to kernel-2.4.18-17.7.x

Please note the fact that the kernel major and minor versions are exactly the same.

My expectation in this kind of security advisory/bug fix update is no major
change in functionality. 

Well, there is. sys_call_table is no longer exported in this bug fix

This means that my Redhat 7.3 based AFS servers and clients cannot 
work since Openafs is dependent on this. 

After stopping all AFS daemons, upgrading the kernel, re-compiling OpenAFS,
that it does not work, rolling everything back, setting up a test bed, spending
1 day 
in various other tests, I finally realize that this design decision
by Alan Cox, which is in some AC patch in some development tree somewhere has made
its way to a security advisory, patch level kernel upgrade for Redhat's 7.3

Please note that the AFS team is aware of the decision in the kernel mailing
list and are 
trying to code their way around it. However, there needs to be more than a few
days lapse time 
before something flies out of Alan Cox's design table and makes its way into our
production servers 
if indeed those servers can remain in production!

1. There needs to be something in the description of the security advisory that
this problem -- I do not expect RedHat to be aware of each and every piece of
3rd party 
software people may be running, but not exporting sys_call_table can be mentioned.

2. Is this patch necessary for this security advisory? I am guessing not. Then
why is it 
released for REdhat 7.3?  I have some test bed machines evaluating Redhat 8.0
and am not
that upset that it broke AFS on 8.0. It is, after all, relatively recent, major
new distribution.

However, I do expect Redhat 7.3 , modulo some needed security updates, to work
as advertised until 
Redhat drops support for it. This is the reason why you have release numbers
etc, right?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Upgrade machine from kernel-2.4.18-10 to 2.4.18-17.7.x
2.Recompile openafs-1.2.7-rh7.3.1.src.rpm
3.rpm -Uvh --force openafs*  (needs to be forced as the openafs rpm version no
is the same, just recompiled for later kernel)
4. /etc/rc.d/init.d/afs start  -- module loading will fail. 

When doing depmod -e on the libafs kernel module, one gets the following error
depmod: *** Unresolved symbols in libafs-2.4.18-17.o
depmod:         sys_call_table


Actual Results:  ??  Could not restart the AFS daemons. Had to roll back the
kernel to the old
version, roll back AFS to the version compiled with the old version and 

AFS and the latest kernel does not play together. So security advisory cannot be

Expected Results:  Should have been able to continue with life as we have been
since we started using REdhat 7.3 as AFS servers and went through 
numerous kernel upgrades. 

I regard this as a security issue since I am not able to follow 
a security advisory because of it. 

Additional info:

Comment 1 Arjan van de Ven 2002-10-19 11:00:28 UTC
"However, there needs to be more than a few days lapse time "

they had about a year

Comment 2 Arjan van de Ven 2002-10-19 11:44:28 UTC
btw as far as I know the AFS people now hack around this by looking up the
symbol from the System.map.

The reason the symbol is removed is because modules using it will clash with the
oprofile functionality that got added to this kernel. 

Comment 3 deniz 2002-10-19 12:16:55 UTC
>"However, there needs to be more than a few days lapse time "

>they had about a year

OK, the bug report does rant, but I think closing it immediately with this
comment is uncalled for. 

Alan Cox did this patch in his tree around April 2002. The following are his own
words regarding this patch: 

"Thats not why it was pulled out. Its a deliberate attempt to find out who
is patching the syscall table and sort the results out.

And btw - I've not submitted this to Marcelo, its not something I expect to
see sprung on people in 2.4.19!"

Seeing this patch then spring up on a 2.4.18 level kernel in an older version of
Redhat (7.3) points out a problem with Redhat's release and maintenance

And as per the second comment -- I have searched the archives and found a
comment or two regarding a hack placed in CVS -- BUT: 

The current released version of OpenAFS -- 1.2.7 does suffer from this issue


As far as I can see, the CVS addition was still on the level of a hack -- there
was talk of PAG being broken as a result of this change. 

So, there is no immediate solution that OpenAFS users can implement with this
kernel, aside from not upgrading to it. 

Best regards,

Comment 4 Arjan van de Ven 2002-10-19 12:31:18 UTC
Alan put this patch in his tree after it had been in the RH tree for a months.
During the ENTIRE 7.3 beta cycle and 8.0 beta cycle this symbol was not there.
We enabled it briefly for the 7.3 release especially for openAFS because the
openAFS people said, on lkml, that they needed extra time to fix it. In the
current kernel there is OPROFILE and that unfortionatly conflicts with other
modules that want to do the very depricated and invasive syscall patching.

As for release policy: Red Hat has never and I assume will never guaranteed that
invasive external kernel modules will keep working between releases of the
kernel. We can't do this normally due to the nature and lack of a real internal
kernel interface for modules. Having said that, the Advanced Server release
tries to maintain stability here as much as possible at the expense of much
higher maintenance and testing costs.

Note You need to log in before you can comment on or make changes to this bug.