Bug#284356: New release changed symbols thus rendering modules unloadable
On Thu, Dec 16, 2004 at 01:24:28PM +0900, Horms wrote: On Wed, Dec 15, 2004 at 12:46:29PM +0100, Christoph Hellwig wrote: On Wed, Dec 15, 2004 at 11:04:40AM +, Martin Michlmayr wrote: * Horms [EMAIL PROTECTED] [2004-12-15 13:28]: I checked 2.6 upstream and the refcount field is present. Curiously upstream 2.4 seems to neither include this field nor a fix for CAN-2004-0814 (N.B not CAN-2004-081 as I misquoted above). If anyone can correct me there I would be most grateful. Thanks for the analysis. Maybe you could contact upstream and ask why it hasn't been included and also mention this compatibility problem. I will contact Marcello, but I am not confident of a reply. Hi Martin, I shouldn't have been so pesemistic. I did indeed get a reply. Several in fact. http://lkml.org/lkml/2004/12/15/299 In a nutshell: 1. This patch wasn't put into 2.4.28 because it was quite intrusive and came out to late in the 2.4.28 cycle 2. It is planed for inclusion (in 2.4.29 I assume) 3. There are some updates to the patch both available and pending, I will make sure we get those, but broadly speaking the patch is unchanged. Actually, I notice that one of the uptades will most likely introduce a futher ABI change by adding struct semaphore termios_sem; to strut tty_struct. It would be good to get that in if we are going to increment the so number. http://lkml.org/lkml/2004/11/7/106 -- Horms
Bug#284356: New release changed symbols thus rendering modules unloadable
* Horms [EMAIL PROTECTED] [2004-12-15 13:28]: I checked 2.6 upstream and the refcount field is present. Curiously upstream 2.4 seems to neither include this field nor a fix for CAN-2004-0814 (N.B not CAN-2004-081 as I misquoted above). If anyone can correct me there I would be most grateful. Thanks for the analysis. Maybe you could contact upstream and ask why it hasn't been included and also mention this compatibility problem. -- Martin Michlmayr http://www.cyrius.com/
Bug#284356: New release changed symbols thus rendering modules unloadable
On Wed, Dec 15, 2004 at 11:04:40AM +, Martin Michlmayr wrote: * Horms [EMAIL PROTECTED] [2004-12-15 13:28]: I checked 2.6 upstream and the refcount field is present. Curiously upstream 2.4 seems to neither include this field nor a fix for CAN-2004-0814 (N.B not CAN-2004-081 as I misquoted above). If anyone can correct me there I would be most grateful. Thanks for the analysis. Maybe you could contact upstream and ask why it hasn't been included and also mention this compatibility problem. It's not a problem. Linux doesn't gurantee any ABI stability.
Bug#284356: New release changed symbols thus rendering modules unloadable
On Wed, Dec 15, 2004 at 01:28:50PM +0900, Horms wrote:
snip
As it stands it seems whe have two choices.
1. Back out the CAN-2004-081 patch.
This is trivial and would resolve the symbol problem.
2. Bump the SO name
i.e. kernel-{build,headers,image,pcmcia-modiles}-2.4.27-1*
- kernel-{build,headers,image,pcmcia-modiles}-2.4.27-2*
This is not fun, but is probably my prefered option at this point.
Theroretically we might be able to do 1+2 but it looks painful at best.
We may also be able to find a way to fix CAN-2004-081 and avoid
introducing this symbol problem, but I am skeptical.
I have built packages that implement each of these plans.
Please take a look if you are interested.
I am still in favour of option 2.
http://debian.vergenet.net/testing/kernel-2.4.27/
--
Horms
Bug#284356: New release changed symbols thus rendering modules unloadable
On Wed, Dec 15, 2004 at 12:46:29PM +0100, Christoph Hellwig wrote: On Wed, Dec 15, 2004 at 11:04:40AM +, Martin Michlmayr wrote: * Horms [EMAIL PROTECTED] [2004-12-15 13:28]: I checked 2.6 upstream and the refcount field is present. Curiously upstream 2.4 seems to neither include this field nor a fix for CAN-2004-0814 (N.B not CAN-2004-081 as I misquoted above). If anyone can correct me there I would be most grateful. Thanks for the analysis. Maybe you could contact upstream and ask why it hasn't been included and also mention this compatibility problem. I will contact Marcello, but I am not confident of a reply. It's not a problem. Linux doesn't gurantee any ABI stability. Agreed. -- Horms
Bug#284356: New release changed symbols thus rendering modules unloadable
On Mon, Dec 13, 2004 at 09:46:56PM +0900, Horms wrote:
On Mon, Dec 06, 2004 at 05:20:08PM +0100, Thomas Hood wrote:
The original report (#284356) was submitted by Joey Hess and made no
reference to proprietary modules. This affects modules shipped by
Debian too.
The problem is that a new Debian release of the same kernel (2.4.27-1)
has changed symbol version suffixes, thus breaking modules that were
compiled against earlier releases of this kernel.
Hi,
I think that I have discovered the cause of the problem.
It seems to be caused by the 093_tty_lockup.diff patch which was applied
to resolve CAN-2004-081, a security bug relating to race
conditions in the TTY subsystem. The patch was sourced from
Jason Baron from Red Hat. I have attached it for reference.
I regret to report that my previous analysis (which I have snipped but
you can find at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=84356)
appears to be incorrect.
On further analysis I believe that the problem lies in the following
portion of the 093_tty_lockup.diff patch at the bottom of this message.
This adds a refcount element to struct tty_ldisc.
Unforunately struct tty_struct includes a element and in turn
struct task_struct includes a struct tty_struct element,
so this change ends up all over the place.
To make matters worse this field appears to be fundamental to
the fix, which I will reiterate at this point is a security fix
for CAN-2004-081.
I checked 2.6 upstream and the refcount field is present.
Curiously upstream 2.4 seems to neither include this field nor
a fix for CAN-2004-0814 (N.B not CAN-2004-081 as I misquoted above).
If anyone can correct me there I would be most grateful.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0814
As it stands it seems whe have two choices.
1. Back out the CAN-2004-081 patch.
This is trivial and would resolve the symbol problem.
2. Bump the SO name
i.e. kernel-{build,headers,image,pcmcia-modiles}-2.4.27-1*
- kernel-{build,headers,image,pcmcia-modiles}-2.4.27-2*
This is not fun, but is probably my prefered option at this point.
Theroretically we might be able to do 1+2 but it looks painful at best.
We may also be able to find a way to fix CAN-2004-081 and avoid
introducing this symbol problem, but I am skeptical.
--
Horms
--- linux-2.4.27/include/linux/tty_ldisc.h.bak Thu Sep 23 17:43:51 2004
+++ linux-2.4.27/include/linux/tty_ldisc.h Thu Sep 23 17:44:24 2004
@@ -129,6 +129,7 @@ struct tty_ldisc {
char *fp, int count);
int (*receive_room)(struct tty_struct *);
void(*write_wakeup)(struct tty_struct *);
+ int refcount;
};
#define TTY_LDISC_MAGIC0x5403
Bug#284356: New release changed symbols thus rendering modules unloadable
On Mon, 13 Dec 2004 21:46:56 +0900, Horms wrote: [...] Hi, I think that I have discovered the cause of the problem. It seems to be caused by the 093_tty_lockup.diff patch which was applied to resolve CAN-2004-081, a security bug relating to race conditions in the TTY subsystem. The patch was sourced from Jason Baron from Red Hat. I have attached it for reference. In testing I found that the problem lies in the following change in include/linux/tty.h -extern struct tty_ldisc ldiscs[]; +extern struct tty_ldisc tty_ldiscs[]; Backing out this change then runing something along the lines of make mrproper cp some_path/some_config .config make oldconfig make dep yields the same symbols. (This test was done using the 686-smp config from kernel-image-i386-2.4.27 -6 and examining the proc_mkdir symbol which is found in include/linux/modules/root.ver) Of course this does not compile because my change is bogus, but I think it does establish the cause of the symbol problem. I believe that there are serveral different fixes for this problem, and in particular the one that was incoporated in 2.6 is somewhat different
Bug#284356: New release changed symbols thus rendering modules unloadable
This bug is release critical. Please do not downgrade it. (But thanks for reopening it.) -- see shy jo signature.asc Description: Digital signature
