linux-kernel - Re: ftrace 'failed to modify' bug when loading reiserfs.ko

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130906035827.GA13446@redhat.com>
Date:	Thu, 5 Sep 2013 23:58:27 -0400
From:	Dave Jones <davej@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: ftrace 'failed to modify' bug when loading reiserfs.ko

On Thu, Sep 05, 2013 at 09:51:54PM -0400, Steven Rostedt wrote:
 > On Thu, 5 Sep 2013 21:48:59 -0400
 > Dave Jones <davej@...hat.com> wrote:
 > 
 > > On Thu, Sep 05, 2013 at 09:44:55PM -0400, Steven Rostedt wrote:
 > >  > On Thu, 5 Sep 2013 21:34:55 -0400
 > >  > Dave Jones <davej@...hat.com> wrote:
 > >  > 
 > >  > > On Thu, Sep 05, 2013 at 09:28:34PM -0400, Steven Rostedt wrote:
 > 
 > >  > Did you change a config option, or update your gcc?
 > > 
 > > Yeah, changed CONFIG_DEBUG_KOBJECT, which rebuilt the world.
 > 
 > Still doesn't explain why it gave you that splat there.
 > 
 > Do you still have that binary module, and can you show me what's at
 > reiserfs_init_bitmap_cache+0x0 with objdump?

I didn't, but it turns out I can recreate this. A little convoluted but..

disable DEBUG_KOBJECT_RELEASE
build, install and boot into kernel

enable DEBUG_KOBJECT_RELEASE
build kernel
install -> boom


00000000000028b0 <reiserfs_init_bitmap_cache>:

        return bh;
}

int reiserfs_init_bitmap_cache(struct super_block *sb)
{
    28b0:       e8 00 00 00 00          callq  28b5 <reiserfs_init_bitmap_cache+0x5>
    28b5:       55                      push   %rbp

/* Don't trust REISERFS_SB(sb)->s_bmap_nr, it's a u16
 * which overflows on large file systems. */
static inline __u32 reiserfs_bmap_count(struct super_block *sb)
{
        return (SB_BLOCK_COUNT(sb) - 1) / (sb->s_blocksize * 8) + 1;
    28b6:       31 d2                   xor    %edx,%edx
    28b8:       48 89 e5                mov    %rsp,%rbp
    28bb:       41 54                   push   %r12
    28bd:       53                      push   %rbx
    28be:       48 89 fb                mov    %rdi,%rbx
    28c1:       48 8b 87 50 07 00 00    mov    0x750(%rdi),%rax
    28c8:       48 8b 77 18             mov    0x18(%rdi),%rsi
    28cc:       48 8b 40 08             mov    0x8(%rax),%rax
    28d0:       48 8d 0c f5 00 00 00    lea    0x0(,%rsi,8),%rcx
    28d7:       00 
    28d8:       8b 00                   mov    (%rax),%eax
    28da:       83 e8 01                sub    $0x1,%eax
    28dd:       48 f7 f1                div    %rcx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/