RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Stephen Hemminger]

QWx0aG91Z2ggY29weSBpcyBzbG93ZXIgZm9yIGxhcmdlIHBhY2tldHMsIHRoaXMgaXMgYSBub24g
cGVyZm9ybWFuY2UgcGF0aC4gVGhlIGNvZGUgaW4gcXVlc3Rpb24gaXMgZm9yIGJyaWRnZWQgbXVs
dGljYXN0IElwdjYgSUNNUCBwYWNrZXRzLiBUaGlzIGNhc2UgaXMgc28gdW5jcml0aWNhbCBpdCBj
b3VsZCBiZSBkb25lIGluIEJBU0lDIGFuZCBubyBvbmUgY291bGQgcG9zc2libHkgY2FyZSEKCiJX
aW5rbGVyLCBUb21hcyIgPHRvbWFzLndpbmtsZXJAaW50ZWwuY29tPiB3cm90ZToKCj4KPgo+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+PiBGcm9tOiBTdGVwaGVuIEhlbW1pbmdlciBbbWFp
bHRvOnNoZW1taW5nZXJAdnlhdHRhLmNvbV0KPj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDMw
LCAyMDEwIDk6MDYgUE0KPj4gVG86IEpvaGFubmVzIEJlcmcKPj4gQ2M6IFdpbmtsZXIsIFRvbWFz
OyBkYXZlbUBkYXZlbWxvZnQubmV0OyBuZXRkZXZAdmdlci5rZXJuZWwub3JnOyBsaW51eC0KPj4g
d2lyZWxlc3NAdmdlci5rZXJuZWwub3JnCj4+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggbmV0LTIuNl0g
YnJpZGdlOiBmaXggYnJfbXVsdGljYXN0X2lwdjZfcmN2IGZvciBwYWdlZAo+PiBza2JzCj4+IAo+
PiBPbiBUaHUsIDMwIERlYyAyMDEwIDE5OjUyOjE0ICswMTAwCj4+IEpvaGFubmVzIEJlcmcgPGpv
aGFubmVzQHNpcHNvbHV0aW9ucy5uZXQ+IHdyb3RlOgo+PiAKPj4gPiBPbiBUaHUsIDIwMTAtMTIt
MzAgYXQgMTA6NDYgLTA4MDAsIFN0ZXBoZW4gSGVtbWluZ2VyIHdyb3RlOgo+PiA+Cj4+ID4gPiBU
aGlzIGRvZXNuJ3QgbG9vayBjb3JyZWN0LiBUaGUgY2FsY3VsYXRpb24gb2YgdGhlIG9mZnNldCBk
b2Vzbid0IGxvb2sKPj4gY29ycmVjdC4KPj4gPiA+IEp1c3QgZm9sbG93aW5nIHRoZSBza2JfY2xv
bmUoKSwgdGhlIHNrYl9wdWxsIHZhbHVlIGlzICJvZmZzZXQiLgo+PiA+ID4gQWxzbywgdGhlIG90
aGVyIGNoZWNrcyByZXR1cm4gLUVJTlZBTCBmb3IgaW5jb3JyZWN0bHkgZm9ybWVkIHBhY2tldC4K
Pj4gPiA+Cj4+ID4gPiAtLS0gYS9uZXQvYnJpZGdlL2JyX211bHRpY2FzdC5jCTIwMTAtMTItMzAg
MTA6Mjk6NTguNTc5NTEwNDg4IC0wODAwCj4+ID4gPiArKysgYi9uZXQvYnJpZGdlL2JyX211bHRp
Y2FzdC5jCTIwMTAtMTItMzAgMTA6NDM6MjcuMjczMzg2NjkxIC0wODAwCj4+ID4gPiBAQCAtMTQ2
NCw2ICsxNDY0LDkgQEAgc3RhdGljIGludCBicl9tdWx0aWNhc3RfaXB2Nl9yY3Yoc3RydWN0Cj4+
ID4gPiAgCWlmIChvZmZzZXQgPCAwIHx8IG5leHRoZHIgIT0gSVBQUk9UT19JQ01QVjYpCj4+ID4g
PiAgCQlyZXR1cm4gMDsKPj4gPiA+Cj4+ID4gPiArCWlmICghcHNrYl9tYXlfcHVsbChza2IsIG9m
ZnNldCkpCj4+ID4gPiArCQlyZXR1cm4gLUVJTlZBTDsKPj4gPiA+ICsKPj4gPiA+ICAJLyogT2th
eSwgd2UgZm91bmQgSUNNUHY2IGhlYWRlciAqLwo+PiA+ID4gIAlza2IyID0gc2tiX2Nsb25lKHNr
YiwgR0ZQX0FUT01JQyk7Cj4+ID4gPiAgCWlmICghc2tiMikKPj4gPgo+PiA+IFdvdWxkbid0IHRo
YXQgbWFrZSBtb3JlIHNlbnNlIGFmdGVyIHRoZSBjbG9uZSBhbnl3YXk/IEJ1dCBpZiB5b3UgbG9v
ayBhdAo+PiA+IG15IGVtYWlsLCB5b3UnbGwgZmluZCB0aGF0IHRoZXJlJ3MgcG90ZW50aWFsbHks
IGFuZCBjb25kaXRpb25hbGx5LCBtb3JlCj4+ID4gc3R1ZmYgdGhhdCB3aWxsIGJlIHJlYWQgZnJv
bSB0aGUgc2tiJ3MgaGVhZGVyLCB3aGljaCBoYXNuJ3QgbmVjZXNzYXJpbHkKPj4gPiBiZWVuIHB1
bGxlZCBpbiwgc28gSSB0aGluayB0aGlzIHN0aWxsIHdvbid0IGZpeCBhbGwgdGhlIGlzc3Vlcy4K
Pj4gPgo+PiA+IFNlZWluZyBob3cgdGhpcyBvbmx5IGFmZmVjdHMgc29tZSBJQ01QdjYgcGFja2V0
cywgbWF5YmUgd2Ugc2hvdWxkIGp1c3QKPj4gPiB1c2Ugc2tiX2NvcHkoKSBpbnN0ZWFkPwo+PiAK
Pj4gSXQgY29tZXMgb3V0IGNsZWFuZXIsIGFuZCB0aGUgY2hlY2sgY2FuIGJlIHNpbXBsaWZpZWQu
Cj4+IAo+PiAtLS0gYS9uZXQvYnJpZGdlL2JyX211bHRpY2FzdC5jCTIwMTAtMTItMzAgMTA6NDc6
MTIuMDMxNzMzODU1IC0wODAwCj4+ICsrKyBiL25ldC9icmlkZ2UvYnJfbXVsdGljYXN0LmMJMjAx
MC0xMi0zMCAxMTowMDoxMi4xMzU4MDEyNjYgLTA4MDAKPj4gQEAgLTE0NjUsMTkgKzE0NjUsMTkg
QEAgc3RhdGljIGludCBicl9tdWx0aWNhc3RfaXB2Nl9yY3Yoc3RydWN0Cj4+ICAJCXJldHVybiAw
Owo+PiAKPj4gIAkvKiBPa2F5LCB3ZSBmb3VuZCBJQ01QdjYgaGVhZGVyICovCj4+IC0Jc2tiMiA9
IHNrYl9jbG9uZShza2IsIEdGUF9BVE9NSUMpOwo+PiArCXNrYjIgPSBza2JfY29weShza2IsIEdG
UF9BVE9NSUMpOwo+PiAgCWlmICghc2tiMikKPj4gIAkJcmV0dXJuIC1FTk9NRU07Cj4+IAo+PiAr
CWVyciA9IC1FSU5WQUw7Cj4+ICsJaWYgKHNrYjItPmxlbiA8IG9mZnNldCArIHNpemVvZigqaWNt
cDZoKSkKPj4gKwkJZ290byBvdXQ7Cj4+ICsKPj4gIAlsZW4gLT0gb2Zmc2V0IC0gc2tiX25ldHdv
cmtfb2Zmc2V0KHNrYjIpOwo+PiAKPj4gIAlfX3NrYl9wdWxsKHNrYjIsIG9mZnNldCk7Cj4+ICAJ
c2tiX3Jlc2V0X3RyYW5zcG9ydF9oZWFkZXIoc2tiMik7Cj4+IAo+PiAtCWVyciA9IC1FSU5WQUw7
Cj4+IC0JaWYgKCFwc2tiX21heV9wdWxsKHNrYjIsIHNpemVvZigqaWNtcDZoKSkpCj4+IC0JCWdv
dG8gb3V0Owo+PiAtCj4+ICAJaWNtcDZoID0gaWNtcDZfaGRyKHNrYjIpOwo+PiAKPj4gIAlzd2l0
Y2ggKGljbXA2aC0+aWNtcDZfdHlwZSkgewo+PiAKPj4KPlNvcnJ5IGZvciBkdW1wIHF1ZXN0aW9u
IGJ1dCBpc24ndCB0aGVyZSBwZXJmb3JtYW5jZSBwZW5hbHR5IG9uIHVzaW5nIHNrYl9jb3B5IHZz
LiBza2JfY2xvbmU/Cj4KPkFueWhvdyBCZWxvdyBpcyBhIGNvZGUgc25pcHBldCBmcm9tIGlwNl9p
bnB1dC5jIHNvIHlvdSBwcm9iYWJseSB3b3VsZCB3YW50IHRvIGZpeCBpdCBhbGwgb3Zlci4gCj5C
VFcgb2Zmc2V0IGFuZCB0aGUgcG9pbnRlciBhcml0aG1ldGljIHJlYWxseSBnaXZlcyB0aGUgc2Ft
ZSBudW1iZXIgKzEsIEknbSBub3Qgc3VybHkgd2h5IHRoZSBvcmlnaW5hbCBhdXRob3Igd291bGQg
dGhvdWdodCBpdCBiZSBzYWZlciB0aGFuIGp1c3QgdXNpbmcgb2Zmc2V0Lgo+Cj4JCQkJCW9mZnNl
dCA9IGlwdjZfc2tpcF9leHRoZHIoc2tiLCBzaXplb2YoKmhkciksCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm5leHRoZHIpOwo+ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBpZiAob2Zmc2V0IDwgMCkKPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBnb3RvIG91dDsKPiAKPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgaWYgKG5leHRoZHIgIT0gSVBQUk9UT19JQ01QVjYpCj4gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZ290byBvdXQ7Cj4gCj4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIGlmICghcHNrYl9tYXlfcHVsbChza2IsIChza2JfbmV0d29y
a19oZWFkZXIoc2tiKSArCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBvZmZzZXQgKyAxIC0gc2tiLT5kYXRhKSkpCj4gICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgZ290byBvdXQ7Cj4gCj4gICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIGljbXA2ID0gKHN0cnVjdCBpY21wNmhkciAqKShza2JfbmV0d29ya19oZWFkZXIo
c2tiKSArIG9mZnNldCk7Cj4KPgo+Cj5UaGFua3MKPlRvbWFzCj4KPgo+LS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj5J
bnRlbCBJc3JhZWwgKDc0KSBMaW1pdGVkCj4KPlRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu
dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFsIGZvcgo+dGhlIHNvbGUgdXNlIG9m
IHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSByZXZpZXcgb3IgZGlzdHJpYnV0aW9uCj5i
eSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu
ZGVkCj5yZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwg
Y29waWVzLgo+Cg==

RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Winkler, Tomas]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlcGhlbiBIZW1taW5n
ZXIgW21haWx0bzpzdGVwaGVuLmhlbW1pbmdlckB2eWF0dGEuY29tXQ0KPiBTZW50OiBGcmlkYXks
IERlY2VtYmVyIDMxLCAyMDEwIDE6MDYgQU0NCj4gVG86IFdpbmtsZXIsIFRvbWFzOyBTdGVwaGVu
IEhlbW1pbmdlcjsgSm9oYW5uZXMgQmVyZw0KPiBDYzogZGF2ZW1AZGF2ZW1sb2Z0Lm5ldDsgbmV0
ZGV2QHZnZXIua2VybmVsLm9yZyA7IGxpbnV4LQ0KPiB3aXJlbGVzc0B2Z2VyLmtlcm5lbC5vcmcN
Cj4gU3ViamVjdDogUkU6IFtQQVRDSCBuZXQtMi42XSBicmlkZ2U6IGZpeCBicl9tdWx0aWNhc3Rf
aXB2Nl9yY3YgZm9yIHBhZ2VkDQo+IHNrYnMNCj4gDQo+IEFsdGhvdWdoIGNvcHkgaXMgc2xvd2Vy
IGZvciBsYXJnZSBwYWNrZXRzLCB0aGlzIGlzIGEgbm9uIHBlcmZvcm1hbmNlIHBhdGguDQo+IFRo
ZSBjb2RlIGluIHF1ZXN0aW9uIGlzIGZvciBicmlkZ2VkIG11bHRpY2FzdCBJcHY2IElDTVAgcGFj
a2V0cy4gVGhpcyBjYXNlDQo+IGlzIHNvIHVuY3JpdGljYWwgaXQgY291bGQgYmUgZG9uZSBpbiBC
QVNJQyBhbmQgbm8gb25lIGNvdWxkIHBvc3NpYmx5IGNhcmUhDQo+IA0KDQoNCkZhaXIgZW5vdWdo
LCBhbHRob3VnaCB5b3UgZ290IGZldyBvZiB0aG9zZSB3aGVuIHlvdSBjb25uZWN0IHRvIHdpbjcg
Y2xpZW50LiANCkFueWhvdyBteSBmaXggd291bGQgd29yayBpZiB0aGUgc2Vjb25kIHB1bGwgd291
bGQgYmUgDQogIGlmICghcHNrYl9tYXlfcHVsbChza2IyLCBzaXplb2Yoc3RydWN0IG1sZF9tc2cp
KSkgIGluc3RlYWQgb2YgICghcHNrYl9tYXlfcHVsbChza2IyLCBzaXplb2YoKmljbXA2aCkpKQ0K
DQpTZWNvbmQgSSB0aGluayBqdXN0IHRoYXQgbm9uIG11bHRpY2FzdCBwbGFjZXMgc2hvdWxkbid0
IGJlIGZpeGVkIGNvbnRyYXJ5IHRvIG15IHByZXZpb3VzIHN1Z2dlc3Rpb24gYXMgdGhlDQpza2Jf
bmV0d29ya19oZWFkZXIoc2tiKSArIG9mZnNldCArIDEgLSBza2ItPmRhdGEgd2lsbCBnaXZlIHlv
dSBjb3JyZWN0IG9mZnNldCB0byBwdWxsIHVwIGlmIHRoZSBuZXR3b3JrIGhlYWRlciBpcyBub3Qg
b24gc2tiLT5kYXRhLg0KDQoNClRoYW5rcw0KVG9tYXMNCg0KPiAiV2lua2xlciwgVG9tYXMiIDx0
b21hcy53aW5rbGVyQGludGVsLmNvbT4gd3JvdGU6DQo+IA0KPiA+DQo+ID4NCj4gPj4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogU3RlcGhlbiBIZW1taW5nZXIgW21haWx0
bzpzaGVtbWluZ2VyQHZ5YXR0YS5jb21dDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAz
MCwgMjAxMCA5OjA2IFBNDQo+ID4+IFRvOiBKb2hhbm5lcyBCZXJnDQo+ID4+IENjOiBXaW5rbGVy
LCBUb21hczsgZGF2ZW1AZGF2ZW1sb2Z0Lm5ldDsgbmV0ZGV2QHZnZXIua2VybmVsLm9yZzsgbGlu
dXgtDQo+ID4+IHdpcmVsZXNzQHZnZXIua2VybmVsLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW1BB
VENIIG5ldC0yLjZdIGJyaWRnZTogZml4IGJyX211bHRpY2FzdF9pcHY2X3JjdiBmb3IgcGFnZWQN
Cj4gPj4gc2ticw0KPiA+Pg0KPiA+PiBPbiBUaHUsIDMwIERlYyAyMDEwIDE5OjUyOjE0ICswMTAw
DQo+ID4+IEpvaGFubmVzIEJlcmcgPGpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXQ+IHdyb3RlOg0K
PiA+Pg0KPiA+PiA+IE9uIFRodSwgMjAxMC0xMi0zMCBhdCAxMDo0NiAtMDgwMCwgU3RlcGhlbiBI
ZW1taW5nZXIgd3JvdGU6DQo+ID4+ID4NCj4gPj4gPiA+IFRoaXMgZG9lc24ndCBsb29rIGNvcnJl
Y3QuIFRoZSBjYWxjdWxhdGlvbiBvZiB0aGUgb2Zmc2V0IGRvZXNuJ3QgbG9vaw0KPiA+PiBjb3Jy
ZWN0Lg0KPiA+PiA+ID4gSnVzdCBmb2xsb3dpbmcgdGhlIHNrYl9jbG9uZSgpLCB0aGUgc2tiX3B1
bGwgdmFsdWUgaXMgIm9mZnNldCIuDQo+ID4+ID4gPiBBbHNvLCB0aGUgb3RoZXIgY2hlY2tzIHJl
dHVybiAtRUlOVkFMIGZvciBpbmNvcnJlY3RseSBmb3JtZWQgcGFja2V0Lg0KPiA+PiA+ID4NCj4g
Pj4gPiA+IC0tLSBhL25ldC9icmlkZ2UvYnJfbXVsdGljYXN0LmMJMjAxMC0xMi0zMCAxMDoyOTo1
OC41Nzk1MTA0ODggLTA4MDANCj4gPj4gPiA+ICsrKyBiL25ldC9icmlkZ2UvYnJfbXVsdGljYXN0
LmMJMjAxMC0xMi0zMCAxMDo0MzoyNy4yNzMzODY2OTEgLTA4MDANCj4gPj4gPiA+IEBAIC0xNDY0
LDYgKzE0NjQsOSBAQCBzdGF0aWMgaW50IGJyX211bHRpY2FzdF9pcHY2X3JjdihzdHJ1Y3QNCj4g
Pj4gPiA+ICAJaWYgKG9mZnNldCA8IDAgfHwgbmV4dGhkciAhPSBJUFBST1RPX0lDTVBWNikNCj4g
Pj4gPiA+ICAJCXJldHVybiAwOw0KPiA+PiA+ID4NCj4gPj4gPiA+ICsJaWYgKCFwc2tiX21heV9w
dWxsKHNrYiwgb2Zmc2V0KSkNCj4gPj4gPiA+ICsJCXJldHVybiAtRUlOVkFMOw0KPiA+PiA+ID4g
Kw0KPiA+PiA+ID4gIAkvKiBPa2F5LCB3ZSBmb3VuZCBJQ01QdjYgaGVhZGVyICovDQo+ID4+ID4g
PiAgCXNrYjIgPSBza2JfY2xvbmUoc2tiLCBHRlBfQVRPTUlDKTsNCj4gPj4gPiA+ICAJaWYgKCFz
a2IyKQ0KPiA+PiA+DQo+ID4+ID4gV291bGRuJ3QgdGhhdCBtYWtlIG1vcmUgc2Vuc2UgYWZ0ZXIg
dGhlIGNsb25lIGFueXdheT8gQnV0IGlmIHlvdSBsb29rDQo+IGF0DQo+ID4+ID4gbXkgZW1haWws
IHlvdSdsbCBmaW5kIHRoYXQgdGhlcmUncyBwb3RlbnRpYWxseSwgYW5kIGNvbmRpdGlvbmFsbHks
IG1vcmUNCj4gPj4gPiBzdHVmZiB0aGF0IHdpbGwgYmUgcmVhZCBmcm9tIHRoZSBza2IncyBoZWFk
ZXIsIHdoaWNoIGhhc24ndCBuZWNlc3NhcmlseQ0KPiA+PiA+IGJlZW4gcHVsbGVkIGluLCBzbyBJ
IHRoaW5rIHRoaXMgc3RpbGwgd29uJ3QgZml4IGFsbCB0aGUgaXNzdWVzLg0KPiA+PiA+DQo+ID4+
ID4gU2VlaW5nIGhvdyB0aGlzIG9ubHkgYWZmZWN0cyBzb21lIElDTVB2NiBwYWNrZXRzLCBtYXli
ZSB3ZSBzaG91bGQganVzdA0KPiA+PiA+IHVzZSBza2JfY29weSgpIGluc3RlYWQ/DQo+ID4+DQo+
ID4+IEl0IGNvbWVzIG91dCBjbGVhbmVyLCBhbmQgdGhlIGNoZWNrIGNhbiBiZSBzaW1wbGlmaWVk
Lg0KPiA+Pg0KPiA+PiAtLS0gYS9uZXQvYnJpZGdlL2JyX211bHRpY2FzdC5jCTIwMTAtMTItMzAg
MTA6NDc6MTIuMDMxNzMzODU1IC0wODAwDQo+ID4+ICsrKyBiL25ldC9icmlkZ2UvYnJfbXVsdGlj
YXN0LmMJMjAxMC0xMi0zMCAxMTowMDoxMi4xMzU4MDEyNjYgLTA4MDANCj4gPj4gQEAgLTE0NjUs
MTkgKzE0NjUsMTkgQEAgc3RhdGljIGludCBicl9tdWx0aWNhc3RfaXB2Nl9yY3Yoc3RydWN0DQo+
ID4+ICAJCXJldHVybiAwOw0KPiA+Pg0KPiA+PiAgCS8qIE9rYXksIHdlIGZvdW5kIElDTVB2NiBo
ZWFkZXIgKi8NCj4gPj4gLQlza2IyID0gc2tiX2Nsb25lKHNrYiwgR0ZQX0FUT01JQyk7DQo+ID4+
ICsJc2tiMiA9IHNrYl9jb3B5KHNrYiwgR0ZQX0FUT01JQyk7DQo+ID4+ICAJaWYgKCFza2IyKQ0K
PiA+PiAgCQlyZXR1cm4gLUVOT01FTTsNCj4gPj4NCj4gPj4gKwllcnIgPSAtRUlOVkFMOw0KPiA+
PiArCWlmIChza2IyLT5sZW4gPCBvZmZzZXQgKyBzaXplb2YoKmljbXA2aCkpDQo+ID4+ICsJCWdv
dG8gb3V0Ow0KPiA+PiArDQo+ID4+ICAJbGVuIC09IG9mZnNldCAtIHNrYl9uZXR3b3JrX29mZnNl
dChza2IyKTsNCj4gPj4NCj4gPj4gIAlfX3NrYl9wdWxsKHNrYjIsIG9mZnNldCk7DQo+ID4+ICAJ
c2tiX3Jlc2V0X3RyYW5zcG9ydF9oZWFkZXIoc2tiMik7DQo+ID4+DQo+ID4+IC0JZXJyID0gLUVJ
TlZBTDsNCj4gPj4gLQlpZiAoIXBza2JfbWF5X3B1bGwoc2tiMiwgc2l6ZW9mKCppY21wNmgpKSkN
Cj4gPj4gLQkJZ290byBvdXQ7DQo+ID4+IC0NCj4gPj4gIAlpY21wNmggPSBpY21wNl9oZHIoc2ti
Mik7DQo+ID4+DQo+ID4+ICAJc3dpdGNoIChpY21wNmgtPmljbXA2X3R5cGUpIHsNCj4gPj4NCj4g
Pj4NCj4gPlNvcnJ5IGZvciBkdW1wIHF1ZXN0aW9uIGJ1dCBpc24ndCB0aGVyZSBwZXJmb3JtYW5j
ZSBwZW5hbHR5IG9uIHVzaW5nDQo+IHNrYl9jb3B5IHZzLiBza2JfY2xvbmU/DQo+ID4NCj4gPkFu
eWhvdyBCZWxvdyBpcyBhIGNvZGUgc25pcHBldCBmcm9tIGlwNl9pbnB1dC5jIHNvIHlvdSBwcm9i
YWJseSB3b3VsZCB3YW50DQo+IHRvIGZpeCBpdCBhbGwgb3Zlci4NCj4gPkJUVyBvZmZzZXQgYW5k
IHRoZSBwb2ludGVyIGFyaXRobWV0aWMgcmVhbGx5IGdpdmVzIHRoZSBzYW1lIG51bWJlciArMSwg
SSdtDQo+IG5vdCBzdXJseSB3aHkgdGhlIG9yaWdpbmFsIGF1dGhvciB3b3VsZCB0aG91Z2h0IGl0
IGJlIHNhZmVyIHRoYW4ganVzdCB1c2luZw0KPiBvZmZzZXQuDQo+ID4NCj4gPgkJCQkJb2Zmc2V0
ID0gaXB2Nl9za2lwX2V4dGhkcihza2IsDQo+IHNpemVvZigqaGRyKSwNCj4gPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmbmV4dGhkcik7
DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChvZmZzZXQgPCAwKQ0KPiA+
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdvdG8gb3V0Ow0KPiA+DQo+
ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIChuZXh0aGRyICE9IElQUFJPVE9f
SUNNUFY2KQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGdvdG8g
b3V0Ow0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmICghcHNrYl9t
YXlfcHVsbChza2IsDQo+IChza2JfbmV0d29ya19oZWFkZXIoc2tiKSArDQo+ID4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvZmZzZXQgKyAxIC0gc2ti
LQ0KPiA+ZGF0YSkpKQ0KPiA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGdvdG8gb3V0Ow0KPiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGljbXA2
ID0gKHN0cnVjdCBpY21wNmhkcg0KPiAqKShza2JfbmV0d29ya19oZWFkZXIoc2tiKSArIG9mZnNl
dCk7DQo+ID4NCj4gPg0KPiA+DQo+ID5UaGFua3MNCj4gPlRvbWFzDQo+ID4NCj4gPg0KPiA+LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQo+ID5JbnRlbCBJc3JhZWwgKDc0KSBMaW1pdGVkDQo+ID4NCj4gPlRoaXMgZS1t
YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFs
IGZvcg0KPiA+dGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy
ZXZpZXcgb3IgZGlzdHJpYnV0aW9uDQo+ID5ieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRl
ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+ID5yZWNpcGllbnQsIHBsZWFzZSBjb250
YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLg0KPiA+DQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K
SW50ZWwgSXNyYWVsICg3NCkgTGltaXRlZAoKVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50
cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRoZSBzb2xlIHVzZSBvZiB0
aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRpc3RyaWJ1dGlvbgpieSBv
dGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk
CnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQgZGVsZXRlIGFsbCBjb3Bp
ZXMuCg==

RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Johannes Berg]

On Fri, 2010-12-31 at 01:29 +0200, Winkler, Tomas wrote:
> 
> > -----Original Message-----
> > From: Stephen Hemminger [mailto:stephen.hemminger@vyatta.com]
> > Sent: Friday, December 31, 2010 1:06 AM
> > To: Winkler, Tomas; Stephen Hemminger; Johannes Berg
> > Cc: davem@davemloft.net; netdev@vger.kernel.org ; linux-
> > wireless@vger.kernel.org
> > Subject: RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
> > skbs
> > 
> > Although copy is slower for large packets, this is a non performance path.
> > The code in question is for bridged multicast Ipv6 ICMP packets. This case
> > is so uncritical it could be done in BASIC and no one could possibly care!
> > 
> 
> 
> Fair enough, although you got few of those when you connect to win7 client. 
> Anyhow my fix would work if the second pull would be 
>   if (!pskb_may_pull(skb2, sizeof(struct mld_msg)))  instead of  (!pskb_may_pull(skb2, sizeof(*icmp6h)))

I don't think that works either since that may be longer than the entire
skb's length since the payload still is variable at this point.

johannes

Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[David Miller]

From: Stephen Hemminger <stephen.hemminger@vyatta.com>
Date: Thu, 30 Dec 2010 15:06:16 -0800

> Although copy is slower for large packets, this is a non performance
> path. The code in question is for bridged multicast Ipv6 ICMP
> packets. This case is so uncritical it could be done in BASIC and no
> one could possibly care!

I still think we should be judicious and keep using skb_clone() here.

Simply combine the two pskb_may_pull() calls into one on "skb2" after
the clone and before the blind __skb_pull() call.  Then add a error
path "out:" called "out_nopush:" for the error path to goto.

Also, I think the "+ 1" in the ipv6 stack code comes from the fact that
the parsing loop can "peek" into the next header's byte to see the type.
And I really don't think it's relevant here.

Also, all of these "x_header + ... + 1 - skb->data" factors are
irrelevent and shouldn't be used.  Just pass "offset + sizeof(*icmp6h)"
to pskb_may_pull().

RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Winkler, Tomas]

> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, December 31, 2010 10:46 PM
> To: stephen.hemminger@vyatta.com
> Cc: Winkler, Tomas; shemminger@vyatta.com; johannes@sipsolutions.net;
> netdev@vger.kernel.org; linux-wireless@vger.kernel.org
> Subject: Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
> skbs
> 
> From: Stephen Hemminger <stephen.hemminger@vyatta.com>
> Date: Thu, 30 Dec 2010 15:06:16 -0800
> 
> > Although copy is slower for large packets, this is a non performance
> > path. The code in question is for bridged multicast Ipv6 ICMP
> > packets. This case is so uncritical it could be done in BASIC and no
> > one could possibly care!
> 
> I still think we should be judicious and keep using skb_clone() here.
> 
> Simply combine the two pskb_may_pull() calls into one on "skb2" after
> the clone and before the blind __skb_pull() call.  Then add a error
> path "out:" called "out_nopush:" for the error path to goto.
> 
> Also, I think the "+ 1" in the ipv6 stack code comes from the fact that
> the parsing loop can "peek" into the next header's byte to see the type.
> And I really don't think it's relevant here.
> 
> Also, all of these "x_header + ... + 1 - skb->data" factors are
> irrelevent and shouldn't be used.  Just pass "offset + sizeof(*icmp6h)"
> to pskb_may_pull().

Sounds reasonable but maybe we shall pass offset + sizeof(struct mld_msg) as *icmp6h is casted to this struct mld_mca is accessed.

struct mld_msg {
        struct icmp6hdr         mld_hdr;
        struct in6_addr         mld_mca;
};

Thanks
Tomas


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: BUG: while bridging Ethernet and wireless device:

[Tomas Winkler]

2010/12/29 Johannes Berg <johannes@sipsolutions.net>:
> On Thu, 2010-12-16 at 14:11 +0200, Tomas Winkler wrote:
>> Will be happy if someone can give me some more insight. (kernel 2.6.37-rc5)
>
> Tomas looked into it a bit more and told me that it happens on IPv6
> packets. To recap, he gets
>
> kernel BUG at include/linux/skbuff.h:1178!
> with
> EIP: [<f83edd65>] br_multicast_rcv+0xc95/0xe1c [bridge]
>
> Also remember that the packets are almost fully nonlinear, when they get
> here they likely have almost no data in the skb header.
>
> I then looked at br_multicast_ipv6_rcv(), and it looks fishy:
>
> Up to:
>        skb2 = skb_clone(skb, GFP_ATOMIC);
>
> everything's fine, since ipv6_skip_exthdr() will use
> skb_header_pointer(). At this point, offset is the result of
> ipv6_skip_exthdr(). Remember that skb_clone() is not skb_copy().

So far I can confirm that switching to sbk_copy fixes the crash.

Thanks
Tomas

[PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Tomas Winkler]

use pskb_may_pull to access header correctly for paged skbs

the pskb_may_pull ideom is used ipv6 heder parsing
but omitted int the bridge code

this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202

Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
Dec 15 14:36:41 User-PC kernel: [175576.122712]
Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G        W   2.6.37-rc5-wl+ #3 1015PE/1016P
Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
Dec 15 14:36:41 User-PC kernel: [175576.123737]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
Dec 15 14:36:41 User-PC kernel: [175576.124181]  ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
Dec 15 14:36:41 User-PC kernel: [175576.124181]  f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
Dec 15 14:36:41 User-PC kernel: [175576.124181]  ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01087d8>] ? sched_clock+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0138264>] ? enqueue_entity+0x174/0x440
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e451>] ? sched_clock_cpu+0x131/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0524fc1>] ? nf_iterate+0x71/0x90
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04f7a30>] ? skb_copy_bits+0x110/0x210
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e242>] ? sched_clock_local+0xb2/0x190
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c012b688>] ? default_spin_lock_flags+0x8/0x10
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150d05>] ? tasklet_action+0xc5/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150a07>] ? __do_softirq+0x97/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150970>] ? __do_softirq+0x0/0x1d0
Dec 15 14:36:41 User-PC kernel: [175576.124181]  <IRQ>
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01508f5>] ? irq_exit+0x65/0x70
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05df062>] ? do_IRQ+0x52/0xc0
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01036b0>] ? common_interrupt+0x30/0x38
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c03a1fc2>] ? intel_idle+0xc2/0x160
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0101dea>] ? cpu_idle+0x8a/0xf0
Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d2702>] ? start_secondary+0x1e8/0x1ee

Cc:YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
 net/bridge/br_multicast.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index f19e347..074c478 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1464,6 +1464,10 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
 	if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
 		return 0;
 
+	if (!pskb_may_pull(skb,
+		(skb_network_header(skb) + offset + 1 - skb->data))) 
+                        return 0;
+
 	/* Okay, we found ICMPv6 header */
 	skb2 = skb_clone(skb, GFP_ATOMIC);
 	if (!skb2)
-- 
1.7.3.4

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Stephen Hemminger]

On Thu, 30 Dec 2010 13:32:33 +0200
Tomas Winkler <tomas.winkler@intel.com> wrote:

> use pskb_may_pull to access header correctly for paged skbs
> 
> the pskb_may_pull ideom is used ipv6 heder parsing
> but omitted int the bridge code
> 
> this fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=25202
> 
> Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: authenticated
> Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 IEEE 802.11: associated (aid 2)
> Dec 15 14:36:40 User-PC hostapd: wlan0: STA 00:15:00:60:5d:34 RADIUS: starting accounting session 4D0608A3-00000005
> Dec 15 14:36:41 User-PC kernel: [175576.120287] ------------[ cut here ]------------
> Dec 15 14:36:41 User-PC kernel: [175576.120452] kernel BUG at include/linux/skbuff.h:1178!
> Dec 15 14:36:41 User-PC kernel: [175576.120609] invalid opcode: 0000 [#1] SMP
> Dec 15 14:36:41 User-PC kernel: [175576.120749] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
> Dec 15 14:36:41 User-PC kernel: [175576.121035] Modules linked in: oprofile binfmt_misc bridge stp llc parport_pc ppdev arc4 iwlagn snd_hda_codec_realtek iwlcore i915 snd_hda_intel mac80211 joydev snd_hda_codec snd_hwdep snd_pcm snd_seq_midi drm_kms_helper snd_rawmidi drm snd_seq_midi_event snd_seq snd_timer snd_seq_device cfg80211 eeepc_wmi usbhid psmouse intel_agp i2c_algo_bit intel_gtt uvcvideo agpgart videodev sparse_keymap snd shpchp v4l1_compat lp hid video serio_raw soundcore output snd_page_alloc ahci libahci atl1c
> Dec 15 14:36:41 User-PC kernel: [175576.122712]
> Dec 15 14:36:41 User-PC kernel: [175576.122769] Pid: 0, comm: kworker/0:0 Tainted: G        W   2.6.37-rc5-wl+ #3 1015PE/1016P
> Dec 15 14:36:41 User-PC kernel: [175576.123012] EIP: 0060:[<f83edd65>] EFLAGS: 00010283 CPU: 1
> Dec 15 14:36:41 User-PC kernel: [175576.123193] EIP is at br_multicast_rcv+0xc95/0xe1c [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.123362] EAX: 0000001c EBX: f5626318 ECX: 00000000 EDX: 00000000
> Dec 15 14:36:41 User-PC kernel: [175576.123550] ESI: ec512262 EDI: f5626180 EBP: f60b5ca0 ESP: f60b5bd8
> Dec 15 14:36:41 User-PC kernel: [175576.123737]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> Dec 15 14:36:41 User-PC kernel: [175576.123902] Process kworker/0:0 (pid: 0, ti=f60b4000 task=f60a8000 task.ti=f60b0000)
> Dec 15 14:36:41 User-PC kernel: [175576.124137] Stack:
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  ec556500 f6d06800 f60b5be8 c01087d8 ec512262 00000030 00000024 f5626180
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  f572c200 ef463440 f5626300 3affffff f6d06dd0 e60766a4 000000c4 f6d06860
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  ffffffff ec55652c 00000001 f6d06844 f60b5c64 c0138264 c016e451 c013e47d
> Dec 15 14:36:41 User-PC kernel: [175576.124181] Call Trace:
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01087d8>] ? sched_clock+0x8/0x10
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0138264>] ? enqueue_entity+0x174/0x440
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e451>] ? sched_clock_cpu+0x131/0x190
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c013e47d>] ? select_task_rq_fair+0x2ad/0x730
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0524fc1>] ? nf_iterate+0x71/0x90
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4914>] ? br_handle_frame_finish+0x184/0x220 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e46e9>] ? br_handle_frame+0x189/0x230 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4790>] ? br_handle_frame_finish+0x0/0x220 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f83e4560>] ? br_handle_frame+0x0/0x230 [bridge]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff026>] ? __netif_receive_skb+0x1b6/0x5b0
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04f7a30>] ? skb_copy_bits+0x110/0x210
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0503a7f>] ? netif_receive_skb+0x6f/0x80
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cb74c>] ? ieee80211_deliver_skb+0x8c/0x1a0 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cc836>] ? ieee80211_rx_handlers+0xeb6/0x1aa0 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04ff1f0>] ? __netif_receive_skb+0x380/0x5b0
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c016e242>] ? sched_clock_local+0xb2/0x190
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c012b688>] ? default_spin_lock_flags+0x8/0x10
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82cd621>] ? ieee80211_prepare_and_rx_handle+0x201/0xa90 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f82ce154>] ? ieee80211_rx+0x2a4/0x830 [mac80211]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f815a8d6>] ? iwl_update_stats+0xa6/0x2a0 [iwlcore]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8499212>] ? iwlagn_rx_reply_rx+0x292/0x3b0 [iwlagn]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d83df>] ? _raw_spin_lock_irqsave+0x2f/0x50
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8483697>] ? iwl_rx_handle+0xe7/0x350 [iwlagn]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<f8486ab7>] ? iwl_irq_tasklet+0xf7/0x5c0 [iwlagn]
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01aece1>] ? __rcu_process_callbacks+0x201/0x2d0
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150d05>] ? tasklet_action+0xc5/0x100
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150a07>] ? __do_softirq+0x97/0x1d0
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d910c>] ? nmi_stack_correct+0x2f/0x34
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0150970>] ? __do_softirq+0x0/0x1d0
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  <IRQ>
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01508f5>] ? irq_exit+0x65/0x70
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05df062>] ? do_IRQ+0x52/0xc0
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c01036b0>] ? common_interrupt+0x30/0x38
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c03a1fc2>] ? intel_idle+0xc2/0x160
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c04daebb>] ? cpuidle_idle_call+0x6b/0x100
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c0101dea>] ? cpu_idle+0x8a/0xf0
> Dec 15 14:36:41 User-PC kernel: [175576.124181]  [<c05d2702>] ? start_secondary+0x1e8/0x1ee
> 
> Cc:YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
> Cc: Johannes Berg <johannes@sipsolutions.net>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> ---
>  net/bridge/br_multicast.c |    4 ++++
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index f19e347..074c478 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1464,6 +1464,10 @@ static int br_multicast_ipv6_rcv(struct net_bridge *br,
>  	if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
>  		return 0;
>  
> +	if (!pskb_may_pull(skb,
> +		(skb_network_header(skb) + offset + 1 - skb->data))) 
> +                        return 0;
> +
>  	/* Okay, we found ICMPv6 header */
>  	skb2 = skb_clone(skb, GFP_ATOMIC);
>  	if (!skb2)

This doesn't look correct. The calculation of the offset doesn't look correct.
Just following the skb_clone(), the skb_pull value is "offset".
Also, the other checks return -EINVAL for incorrectly formed packet.

--- a/net/bridge/br_multicast.c	2010-12-30 10:29:58.579510488 -0800
+++ b/net/bridge/br_multicast.c	2010-12-30 10:43:27.273386691 -0800
@@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
 	if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
 		return 0;
 
+	if (!pskb_may_pull(skb, offset))
+		return -EINVAL;
+
 	/* Okay, we found ICMPv6 header */
 	skb2 = skb_clone(skb, GFP_ATOMIC);
 	if (!skb2)



-- 

Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Johannes Berg]

On Thu, 2010-12-30 at 10:46 -0800, Stephen Hemminger wrote:

> This doesn't look correct. The calculation of the offset doesn't look correct.
> Just following the skb_clone(), the skb_pull value is "offset".
> Also, the other checks return -EINVAL for incorrectly formed packet.
> 
> --- a/net/bridge/br_multicast.c	2010-12-30 10:29:58.579510488 -0800
> +++ b/net/bridge/br_multicast.c	2010-12-30 10:43:27.273386691 -0800
> @@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
>  	if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
>  		return 0;
>  
> +	if (!pskb_may_pull(skb, offset))
> +		return -EINVAL;
> +
>  	/* Okay, we found ICMPv6 header */
>  	skb2 = skb_clone(skb, GFP_ATOMIC);
>  	if (!skb2)

Wouldn't that make more sense after the clone anyway? But if you look at
my email, you'll find that there's potentially, and conditionally, more
stuff that will be read from the skb's header, which hasn't necessarily
been pulled in, so I think this still won't fix all the issues.

Seeing how this only affects some ICMPv6 packets, maybe we should just
use skb_copy() instead?

johannes

Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Stephen Hemminger]

On Thu, 30 Dec 2010 19:52:14 +0100
Johannes Berg <johannes@sipsolutions.net> wrote:

> On Thu, 2010-12-30 at 10:46 -0800, Stephen Hemminger wrote:
> 
> > This doesn't look correct. The calculation of the offset doesn't look correct.
> > Just following the skb_clone(), the skb_pull value is "offset".
> > Also, the other checks return -EINVAL for incorrectly formed packet.
> > 
> > --- a/net/bridge/br_multicast.c	2010-12-30 10:29:58.579510488 -0800
> > +++ b/net/bridge/br_multicast.c	2010-12-30 10:43:27.273386691 -0800
> > @@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
> >  	if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
> >  		return 0;
> >  
> > +	if (!pskb_may_pull(skb, offset))
> > +		return -EINVAL;
> > +
> >  	/* Okay, we found ICMPv6 header */
> >  	skb2 = skb_clone(skb, GFP_ATOMIC);
> >  	if (!skb2)
> 
> Wouldn't that make more sense after the clone anyway? But if you look at
> my email, you'll find that there's potentially, and conditionally, more
> stuff that will be read from the skb's header, which hasn't necessarily
> been pulled in, so I think this still won't fix all the issues.
> 
> Seeing how this only affects some ICMPv6 packets, maybe we should just
> use skb_copy() instead?

It comes out cleaner, and the check can be simplified.

--- a/net/bridge/br_multicast.c	2010-12-30 10:47:12.031733855 -0800
+++ b/net/bridge/br_multicast.c	2010-12-30 11:00:12.135801266 -0800
@@ -1465,19 +1465,19 @@ static int br_multicast_ipv6_rcv(struct
 		return 0;
 
 	/* Okay, we found ICMPv6 header */
-	skb2 = skb_clone(skb, GFP_ATOMIC);
+	skb2 = skb_copy(skb, GFP_ATOMIC);
 	if (!skb2)
 		return -ENOMEM;
 
+	err = -EINVAL;
+	if (skb2->len < offset + sizeof(*icmp6h))
+		goto out;
+
 	len -= offset - skb_network_offset(skb2);
 
 	__skb_pull(skb2, offset);
 	skb_reset_transport_header(skb2);
 
-	err = -EINVAL;
-	if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
-		goto out;
-
 	icmp6h = icmp6_hdr(skb2);
 
 	switch (icmp6h->icmp6_type) {



-- 

RE: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged skbs

[Winkler, Tomas]

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Thursday, December 30, 2010 9:06 PM
> To: Johannes Berg
> Cc: Winkler, Tomas; davem@davemloft.net; netdev@vger.kernel.org; linux-
> wireless@vger.kernel.org
> Subject: Re: [PATCH net-2.6] bridge: fix br_multicast_ipv6_rcv for paged
> skbs
> 
> On Thu, 30 Dec 2010 19:52:14 +0100
> Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> > On Thu, 2010-12-30 at 10:46 -0800, Stephen Hemminger wrote:
> >
> > > This doesn't look correct. The calculation of the offset doesn't look
> correct.
> > > Just following the skb_clone(), the skb_pull value is "offset".
> > > Also, the other checks return -EINVAL for incorrectly formed packet.
> > >
> > > --- a/net/bridge/br_multicast.c	2010-12-30 10:29:58.579510488 -0800
> > > +++ b/net/bridge/br_multicast.c	2010-12-30 10:43:27.273386691 -0800
> > > @@ -1464,6 +1464,9 @@ static int br_multicast_ipv6_rcv(struct
> > >  	if (offset < 0 || nexthdr != IPPROTO_ICMPV6)
> > >  		return 0;
> > >
> > > +	if (!pskb_may_pull(skb, offset))
> > > +		return -EINVAL;
> > > +
> > >  	/* Okay, we found ICMPv6 header */
> > >  	skb2 = skb_clone(skb, GFP_ATOMIC);
> > >  	if (!skb2)
> >
> > Wouldn't that make more sense after the clone anyway? But if you look at
> > my email, you'll find that there's potentially, and conditionally, more
> > stuff that will be read from the skb's header, which hasn't necessarily
> > been pulled in, so I think this still won't fix all the issues.
> >
> > Seeing how this only affects some ICMPv6 packets, maybe we should just
> > use skb_copy() instead?
> 
> It comes out cleaner, and the check can be simplified.
> 
> --- a/net/bridge/br_multicast.c	2010-12-30 10:47:12.031733855 -0800
> +++ b/net/bridge/br_multicast.c	2010-12-30 11:00:12.135801266 -0800
> @@ -1465,19 +1465,19 @@ static int br_multicast_ipv6_rcv(struct
>  		return 0;
> 
>  	/* Okay, we found ICMPv6 header */
> -	skb2 = skb_clone(skb, GFP_ATOMIC);
> +	skb2 = skb_copy(skb, GFP_ATOMIC);
>  	if (!skb2)
>  		return -ENOMEM;
> 
> +	err = -EINVAL;
> +	if (skb2->len < offset + sizeof(*icmp6h))
> +		goto out;
> +
>  	len -= offset - skb_network_offset(skb2);
> 
>  	__skb_pull(skb2, offset);
>  	skb_reset_transport_header(skb2);
> 
> -	err = -EINVAL;
> -	if (!pskb_may_pull(skb2, sizeof(*icmp6h)))
> -		goto out;
> -
>  	icmp6h = icmp6_hdr(skb2);
> 
>  	switch (icmp6h->icmp6_type) {
> 
>
Sorry for dump question but isn't there performance penalty on using skb_copy vs. skb_clone?

Anyhow Below is a code snippet from ip6_input.c so you probably would want to fix it all over. 
BTW offset and the pointer arithmetic really gives the same number +1, I'm not surly why the original author would thought it be safer than just using offset.

					offset = ipv6_skip_exthdr(skb, sizeof(*hdr),
                                                          &nexthdr);
                                if (offset < 0)
                                        goto out;
 
                                if (nexthdr != IPPROTO_ICMPV6)
                                        goto out;
 
                                if (!pskb_may_pull(skb, (skb_network_header(skb) +
                                                   offset + 1 - skb->data)))
                                        goto out;
 
                                icmp6 = (struct icmp6hdr *)(skb_network_header(skb) + offset);



Thanks
Tomas


---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.