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
| ||
|
Date: Wed, 31 Oct 2012 14:36:23 -0500 From: Trey Ramsay <tramsay@...ux.vnet.ibm.com> To: linux-kernel@...r.kernel.org CC: cjb@...top.org Subject: drivers/mmc/card/block.c infinite loop in mmc_blk_err_check waiting on R1_READY_FOR_DATA In the 3.7-rc3 kernel, there is an infinite loop in the mmc_blk_err_check() function in drivers/mmc/card/block.c that can be caused bad hardware. This loop has moved around a little, but appears to have been around in the kernel since v2.6.12. The code will loop forever on write if the card isn't ready for data or if it's in program mode. I did some searching and saw that it was reported to linux-mmc@...r.kernel.org http://permalink.gmane.org/gmane.linux.kernel.mmc/2021 back in May but didn't see a response. Should there be a maximum retry count or a timeout to prevent an infinite loop? 1030 /* 1031 * Everything else is either success, or a data error of some 1032 * kind. If it was a write, we may have transitioned to 1033 * program mode, which we have to wait for it to complete. 1034 */ 1035 if (!mmc_host_is_spi(card->host) && rq_data_dir(req) != READ) { 1036 u32 status; 1037 do { 1038 int err = get_card_status(card, &status, 5); 1039 if (err) { 1040 pr_err("%s: error %d requesting status\n", 1041 req->rq_disk->disk_name, err); 1042 return MMC_BLK_CMD_ERR; 1043 } 1044 /* 1045 * Some cards mishandle the status bits, 1046 * so make sure to check both the busy 1047 * indication and the card state. 1048 */ 1049 } while (!(status & R1_READY_FOR_DATA) || 1050 (R1_CURRENT_STATE(status) == R1_STATE_PRG)); 1051 } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists