Christian Gennerat wrote :
> Il s'agit d'un message multivolet au format MIME.
Sans commentaires ;-)
> But, I have frequent panics, on the PCI side.
> not at the same address.
> The last one is in:
> irlap_recv_discovery_xid_cmd [irlap_frame.c]
> discovery->hints.byte[0] = discovery_info[0];
> where the pointer discovery_info is Null.
Good catch ! This is a case of "it should never happen".
Basically, the beggining of the discovery frame is totally
valid, it's just that it's too short (the packet indicates that it's a
long discovery frame, but it's size is like a short discovery frame).
What I suspect is that the CRC check of the toshoboe driver
let pass lot's of garbage. The IrDA stack doesn't check yet all those
cases. It could also be a malformated discovery packet sent by the
other end (Dag, could it ever be remotely possible ?).
The attached patch will fix the crash. This is quick and
dirty. Anyway, don't worry, if the driver pass garbage the IrDA stack,
it will crash elsewhere :-(
By the way, Dag has authored a more recent IrDA patch
integrating my stuff, but it hasn't appeared yet on the ftp...
A+
Jean
diff -u -p irlap_frame.d5.c irlap_frame.c
--- irlap_frame.d5.c Mon Nov 6 09:58:47 2000
+++ irlap_frame.c Mon Nov 6 10:14:05 2000
@@ -502,6 +502,13 @@ static void irlap_recv_discovery_xid_cmd
* Check if last frame
*/
if (info->s == 0xff) {
+ /* Check if things are sane at this point... */
+ if((discovery_info == NULL) || (skb->len < 3)) {
+ ERROR(__FUNCTION__ "(), discovery frame to short!\n");
+ dev_kfree_skb(skb);
+ return;
+ }
+
/*
* We now have some discovery info to deliver!
*/
