| Message ID | 51496CC5.7040400@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBsaW51eC1uZnMtb3duZXJAdmdl ci5rZXJuZWwub3JnIFttYWlsdG86bGludXgtbmZzLW93bmVyQHZnZXIua2VybmVsLm9yZ10gT24g QmVoYWxmIE9mDQo+IGZhbmNoYW90aW5nDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjAsIDIw MTMgNDowMSBQTQ0KPiBUbzogTXlrbGVidXN0LCBUcm9uZA0KPiBDYzogbGludXgtbmZzQHZnZXIu a2VybmVsLm9yZw0KPiBTdWJqZWN0OiBbUEFUQ0hdIHBuZnMtYmxvY2s6IHJlbW92aW5nIERNIGRl dmljZSBtYXliZSBjYXVzZSBvb3BzIHdoZW4gY2FsbCBkZXZfcmVtb3ZlDQo+IA0KPiB3aGVuIHBu ZnMgYmxvY2sgdXNpbmcgZGV2aWNlIG1hcHBlcixpZiB1bW91bnRpbmcgbGF0ZXIsaXQgbWF5YmUN Cj4gY2F1c2Ugb29wcy4gd2UgYXBwbHkgIjEgKyBzaXplb2YoYmxfdW1vdW50X3JlcXVlc3QpIiBt ZW1vcnkgZm9yDQo+IG1zZy0+ZGF0YSwgdGhlIG1lbW9yeSBtYXliZSBvdmVyZmxvdyB3aGVuIHdl IGRvICJtZW1jcHkoJmRhdGFwdHINCj4gW3NpemVvZihibF9tc2cpXSwgJmJsX3Vtb3VudF9yZXF1 ZXN0LCBzaXplb2YoYmxfdW1vdW50X3JlcXVlc3QpKSIsDQo+IGJlY2F1c2UgdGhlIHNpemUgb2Yg YmxfbXNnIGlzIG1vcmUgdGhhbiAxIGJ5dGUuDQo+IA0KTmljZSBjYXRjaCEgSSB0aGluayB3ZSBk aWRuJ3QgY3Jhc2ggYmVmb3JlIGp1c3QgYmVjYXVzZSBvZiBkYXRhIGFsaWdubWVudCAoYW5kIGx1 Y2sgZm9yIHN1cmUgOi0pLg0KDQpUaGFua3MsDQpUYW8NCj4gICAgU2lnbmVkLW9mZi1ieTogZmFu Y2hhb3Rpbmc8ZmFuY2hhb3RpbmdAY24uZnVqaXRzdS5jb20+DQo+IA0KPiAtLS0NCj4gIGZzL25m cy9ibG9ja2xheW91dC9ibG9ja2xheW91dGRtLmMgfCAgICAyICstDQo+ICAxIGZpbGVzIGNoYW5n ZWQsIDEgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbnMoLSkNCj4gDQo+IGRpZmYgLS1naXQgYS9m cy9uZnMvYmxvY2tsYXlvdXQvYmxvY2tsYXlvdXRkbS5jIGIvZnMvbmZzL2Jsb2NrbGF5b3V0L2Js b2NrbGF5b3V0ZG0uYw0KPiBpbmRleCA3MzdkODM5Li44ZGY5YWZhIDEwMDY0NA0KPiAtLS0gYS9m cy9uZnMvYmxvY2tsYXlvdXQvYmxvY2tsYXlvdXRkbS5jDQo+ICsrKyBiL2ZzL25mcy9ibG9ja2xh eW91dC9ibG9ja2xheW91dGRtLmMNCj4gQEAgLTU1LDcgKzU1LDcgQEAgc3RhdGljIHZvaWQgZGV2 X3JlbW92ZShzdHJ1Y3QgbmV0ICpuZXQsIGRldl90IGRldikNCj4gDQo+ICAgICAgICAgYmxfcGlw ZV9tc2cuYmxfd3EgPSAmbm4tPmJsX3dxOw0KPiAgICAgICAgIG1lbXNldChtc2csIDAsIHNpemVv ZigqbXNnKSk7DQo+IC0gICAgICAgbXNnLT5kYXRhID0ga3phbGxvYygxICsgc2l6ZW9mKGJsX3Vt b3VudF9yZXF1ZXN0KSwgR0ZQX05PRlMpOw0KPiArICAgICAgIG1zZy0+ZGF0YSA9IGt6YWxsb2Mo c2l6ZW9mKGJsX21zZykgKyBzaXplb2YoYmxfdW1vdW50X3JlcXVlc3QpLCBHRlBfTk9GUyk7DQo+ ICAgICAgICAgaWYgKCFtc2ctPmRhdGEpDQo+ICAgICAgICAgICAgICAgICBnb3RvIG91dDsNCj4g DQo+IC0tDQo+IDEuNy4xDQo+IA0KPiAtLQ0KPiBUbyB1bnN1YnNjcmliZSBmcm9tIHRoaXMgbGlz dDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtbmZzIiBpbg0KPiB0aGUgYm9keSBv ZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0KPiBNb3JlIG1ham9yZG9t byBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1pbmZvLmh0bWwNCg0K -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2013-03-20 at 16:01 +0800, fanchaoting wrote: > when pnfs block using device mapper,if umounting later,it maybe > cause oops. we apply "1 + sizeof(bl_umount_request)" memory for > msg->data, the memory maybe overflow when we do "memcpy(&dataptr > [sizeof(bl_msg)], &bl_umount_request, sizeof(bl_umount_request))", > because the size of bl_msg is more than 1 byte. > > Signed-off-by: fanchaoting<fanchaoting@cn.fujitsu.com> > > --- > fs/nfs/blocklayout/blocklayoutdm.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/fs/nfs/blocklayout/blocklayoutdm.c b/fs/nfs/blocklayout/blocklayoutdm.c > index 737d839..8df9afa 100644 > --- a/fs/nfs/blocklayout/blocklayoutdm.c > +++ b/fs/nfs/blocklayout/blocklayoutdm.c > @@ -55,7 +55,7 @@ static void dev_remove(struct net *net, dev_t dev) > > bl_pipe_msg.bl_wq = &nn->bl_wq; > memset(msg, 0, sizeof(*msg)); > - msg->data = kzalloc(1 + sizeof(bl_umount_request), GFP_NOFS); > + msg->data = kzalloc(sizeof(bl_msg) + sizeof(bl_umount_request), GFP_NOFS); > if (!msg->data) > goto out; > Why not just move the calculation of msg->len, and then use msg->len in the above allocation?
diff --git a/fs/nfs/blocklayout/blocklayoutdm.c b/fs/nfs/blocklayout/blocklayoutdm.c index 737d839..8df9afa 100644 --- a/fs/nfs/blocklayout/blocklayoutdm.c +++ b/fs/nfs/blocklayout/blocklayoutdm.c @@ -55,7 +55,7 @@ static void dev_remove(struct net *net, dev_t dev) bl_pipe_msg.bl_wq = &nn->bl_wq; memset(msg, 0, sizeof(*msg)); - msg->data = kzalloc(1 + sizeof(bl_umount_request), GFP_NOFS); + msg->data = kzalloc(sizeof(bl_msg) + sizeof(bl_umount_request), GFP_NOFS); if (!msg->data) goto out;
when pnfs block using device mapper,if umounting later,it maybe cause oops. we apply "1 + sizeof(bl_umount_request)" memory for msg->data, the memory maybe overflow when we do "memcpy(&dataptr [sizeof(bl_msg)], &bl_umount_request, sizeof(bl_umount_request))", because the size of bl_msg is more than 1 byte. Signed-off-by: fanchaoting<fanchaoting@cn.fujitsu.com> --- fs/nfs/blocklayout/blocklayoutdm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html