netdev - [PATCH 1/5] defxx: Correct the receive DMA map size

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: <alpine.LFD.2.11.1407020544430.15455@eddie.linux-mips.org>
Date:	Sat, 5 Jul 2014 15:14:22 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	netdev@...r.kernel.org
cc:	Robert Coerver <Robert.Coerver@...mit.edu>
Subject: [PATCH 1/5] defxx: Correct the receive DMA map size

Receive DMA maps are oversized, they include EISA legacy 128-byte
alignment padding in size calculation whereas this padding is never used
for data.  Worse yet, if the skb's data area has been realigned indeed,
then data beyond the end of the buffer will be synchronised from the
receive DMA bounce buffer, possibly corrupting data structures residing
in memory beyond the actual end of this data buffer.

Therefore switch to using PI_RCV_DATA_K_SIZE_MAX rather than NEW_SKB_SIZE
in DMA mapping, the value the former macro expands to is written to the
receive ring DMA descriptor of the PDQ DMA chip and determines the
maximum amount of data PDQ will ever transfer to the corresponding data
buffer, including all headers and padding.

Reported-by: Robert Coerver <Robert.Coerver@...mit.edu>
Tested-by: Robert Coerver <Robert.Coerver@...mit.edu>
Signed-off-by: Maciej W. Rozycki <macro@...ux-mips.org>
---
 Please apply,

  Maciej

linux-defxx-rx-dma-map-size.patch
Index: linux-20140623-swarm64-eb/drivers/net/fddi/defxx.c
===================================================================
--- linux-20140623-swarm64-eb.orig/drivers/net/fddi/defxx.c
+++ linux-20140623-swarm64-eb/drivers/net/fddi/defxx.c
@@ -2940,7 +2940,7 @@ static int dfx_rcv_init(DFX_board_t *bp,
 			my_skb_align(newskb, 128);
 			bp->descr_block_virt->rcv_data[i + j].long_1 =
 				(u32)dma_map_single(bp->bus_dev, newskb->data,
-						    NEW_SKB_SIZE,
+						    PI_RCV_DATA_K_SIZE_MAX,
 						    DMA_FROM_DEVICE);
 			/*
 			 * p_rcv_buff_va is only used inside the
@@ -3057,14 +3057,14 @@ static void dfx_rcv_queue_process(
 						skb = (struct sk_buff *)bp->p_rcv_buff_va[entry];
 						dma_unmap_single(bp->bus_dev,
 							bp->descr_block_virt->rcv_data[entry].long_1,
-							NEW_SKB_SIZE,
+							PI_RCV_DATA_K_SIZE_MAX,
 							DMA_FROM_DEVICE);
 						skb_reserve(skb, RCV_BUFF_K_PADDING);
 						bp->p_rcv_buff_va[entry] = (char *)newskb;
 						bp->descr_block_virt->rcv_data[entry].long_1 =
 							(u32)dma_map_single(bp->bus_dev,
 								newskb->data,
-								NEW_SKB_SIZE,
+								PI_RCV_DATA_K_SIZE_MAX,
 								DMA_FROM_DEVICE);
 					} else
 						skb = NULL;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html