grsecurity forums

Hi,

On 3.2.68 in a Xen dom0 I get an oops upon loading (drivers/staging/)rts5139 which supports a USB cardreader. I suspect this is yet another case of the DRM-on-stacks I see fixes for in the grsec changelog (especially in that staging body of code from that era). Since my root fs is on there and grsec forces a reboot, this is transcribed from a hasty photo. I've made the wild, uneducated, lazy guess that the offending code will be obvious to you so abridged the trace and just included the call chain; if it's not enough, please say and I'll transcribe everything.

Code: Select all

kernel BUG at include/asm-generic/dma-mapping-common.h:19!
invalid opcode: 0000 [#1] SMP
Modules linked in: rts5139
Pid:217, comm: rts5139-control ...
RIP ... dma_map_single_attrs.constprop.27+0x3e/0x99
...
Call Trace:
 usb_hcd_map_urb_for_dma
 put_dec
 get_phys_to_machine
 usb_hcd_submit_urb
 arch_local_irq_restore
 xen_mc_flush
 rts51x_msg_common
 rts51x_get_epc_status
 rts51x_get_card_status
 card_cd_debounce
 rts51x_init_cards
 rts51x_scsi_handler
 arch_local_irq_enable
 rts51x_disconnect
 rts51x_invoke_transport
 rts51x_control_thread
 kthread
 kernel_thread_helper
 gs_change


The module worked in 3.2.58 but broke in 3.2.63+; I assume grsec got more strict? The kernel is vanilla kernel.org + grsec. I think other non-staging code from the same author has had fixes applied upstream for similar issues (ums-realtek in drivers/usb/storage/realtek_cr.c which optionally handles power management for the same hardware) so I'd expect this to take several iterations. rts5139 escaped staging in 3.16.x (becoming drivers/mfd/rtsx_usb) but I'd rather stick with stable series if I can and I'm treating backporting rtsx_usb as a last resort since I expect I'd be out of my depth.

rts5139 really is the only module, and only because it fails to load if built in.

Edit: grsecurity-3.1-3.2.68-201503092202 for avoidance of doubt.

Thanks in advance.

z80

yes, it's a DMA on stack problem, in particular in drivers/staging/rts5139/rts51x_chip.c:rts51x_get_card_status where "u16 val" should instead be kmalloc'ed. from a quick browsing of the code there're several other instances of this problem though (e.g., buf in ext_sd_send_cmd_get_rsp which gets passed down a few callers before reaching the DMA check). now to be honest after 3 years support for 3.2 is winding down on our side so i'm not sure we want to spend this time on a staging driver in there. could you perhaps consider moving to 3.14 and we'd fix this there instead?

I will fix this for the next patches.

Thanks for the report,
-Brad