| Summary: | =sys-kernel/hardened-sources-3.19.3: crash: PAX: size overflow detected in function async_copy_data.isra.38 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | jack_mort <jackmort37> |
| Component: | Hardened | Assignee: | The Gentoo Linux Hardened Team <hardened> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | pageexec, re.emese, spender |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Stack trace + debug from raid5.c
Stack trace from 3.19.3-r1 |
||
|
Description
jack_mort
2015-04-04 10:26:58 UTC
please see https://bugs.gentoo.org/show_bug.cgi?id=545192#c8 for further instructions to help us debug this. Created attachment 400694 [details] Stack trace + debug from raid5.c Here we will find the raid5.c.* files compiled with the EXTRA_CFLAGS : https://www.dropbox.com/s/jpdjc660uoyqvi0/raid5.c_star.tar.bz2?dl=0 And also attached is the stack trace with frame pointer enabled. can you give the following patch a try:
--- a/drivers/md/raid5.c 2015-03-08 00:50:15.749728367 +0100
+++ b/drivers/md/raid5.c 2015-04-07 20:32:12.559605536 +0200
@@ -950,14 +950,14 @@
struct bio_vec bvl;
struct bvec_iter iter;
struct page *bio_page;
- int page_offset;
+ s64 page_offset;
struct async_submit_ctl submit;
enum async_tx_flags flags = 0;
if (bio->bi_iter.bi_sector >= sector)
- page_offset = (signed)(bio->bi_iter.bi_sector - sector) * 512;
+ page_offset = (s64)(bio->bi_iter.bi_sector - sector) * 512;
else
- page_offset = (signed)(sector - bio->bi_iter.bi_sector) * -512;
+ page_offset = (s64)(sector - bio->bi_iter.bi_sector) * -512;
if (frombio)
flags |= ASYNC_TX_FENCE;
I couldn't catch the error (I wasn't under ssh, only console) but, with the patch I got the same issue. I can try to get the error later if you need. (In reply to jack_mort from comment #4) > I couldn't catch the error (I wasn't under ssh, only console) but, with the > patch I got the same issue. it can't be the same problem as with the patch that place doesn't get instrumented anymore, but i can confirm it if you generate and upload a new set of raid5.c.* files. > I can try to get the error later if you need. yes please ;). Created attachment 401040 [details] Stack trace from 3.19.3-r1 Hi, I've added new stack trace from 3.19.3-r1, and here are the raid5.c* files : https://www.dropbox.com/s/bnwiku9tyfziahy/raid5.c_star.tar.bz2?dl=0 It's hard to test, because it's overstressing my raid array : as soon as I get the infamous size overflow, raid detects an error in the array and starts a rebuild :-/ sorry for your troubles but gcc induced integer overflows are hard to handle... in any case, if you feel like doing one (hopefully) last test, can you revert the previous patch and apply this one instead please:
--- a/drivers/md/raid5.c 2015-03-18 15:21:50.408349253 +0100
+++ b/drivers/md/raid5.c 2015-04-12 18:02:35.037337098 +0200
@@ -950,23 +950,23 @@
struct bio_vec bvl;
struct bvec_iter iter;
struct page *bio_page;
- int page_offset;
+ long page_offset;
struct async_submit_ctl submit;
enum async_tx_flags flags = 0;
if (bio->bi_iter.bi_sector >= sector)
- page_offset = (signed)(bio->bi_iter.bi_sector - sector) * 512;
+ page_offset = (long)(bio->bi_iter.bi_sector - sector) * 512;
else
- page_offset = (signed)(sector - bio->bi_iter.bi_sector) * -512;
+ page_offset = (long)(sector - bio->bi_iter.bi_sector) * -512;
if (frombio)
flags |= ASYNC_TX_FENCE;
init_async_submit(&submit, flags, tx, NULL, NULL, NULL);
bio_for_each_segment(bvl, bio, iter) {
- int len = bvl.bv_len;
- int clen;
- int b_offset = 0;
+ long len = bvl.bv_len;
+ long clen;
+ long b_offset = 0;
if (page_offset < 0) {
b_offset = -page_offset;
Sorry, I had no time to test the new patch. I'll try to test by the end of the week. (In reply to jack_mort from comment #8) > Sorry, I had no time to test the new patch. I'll try to test by the end of > the week. I yanked 3.19.3 from the tree. Can you try with 3.19.4. I also had this same problem on 3.19.3. I did not get a chance to try 3.19.4, but I don't seem to be experiencing the problem in 3.19.5, so I'm not sure where or if it really got fixed. (In reply to dB from comment #10) > I also had this same problem on 3.19.3. I did not get a chance to try > 3.19.4, but I don't seem to be experiencing the problem in 3.19.5, so I'm > not sure where or if it really got fixed. i already released the fix in a later patch for 3.19.3 so that would explain it ;). if others who experienced the issue can also confirm it then we can close this bug. I may have failed something but for now, I can't boot 3.19.5... Back to 3.18.9 to rebuild a fresh 3.19.5 and get another try. OK, I could run another test, and 3.19.5 booted fine... with no size overflow after a few hours uptime ! It seems to be fixed for me, thanks for the support :-) (In reply to jack_mort from comment #13) > OK, I could run another test, and 3.19.5 booted fine... with no size > overflow after a few hours uptime ! > It seems to be fixed for me, thanks for the support :-) Thanks. |
