CVE-2024-56589

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: hisi_sas: Add cond_resched() for no forced preemption model<br /> <br /> For no forced preemption model kernel, in the scenario where the<br /> expander is connected to 12 high performance SAS SSDs, the following<br /> call trace may occur:<br /> <br /> [ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211]<br /> [ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)<br /> [ 214.575224][ C240] pc : fput_many+0x8c/0xdc<br /> [ 214.579480][ C240] lr : fput+0x1c/0xf0<br /> [ 214.583302][ C240] sp : ffff80002de2b900<br /> [ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000<br /> [ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000<br /> [ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000<br /> [ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001<br /> [ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000<br /> [ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000<br /> [ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0<br /> [ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff<br /> [ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c<br /> [ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0<br /> [ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001<br /> [ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080<br /> [ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554<br /> [ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020<br /> [ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8<br /> [ 214.677191][ C240] Call trace:<br /> [ 214.680320][ C240] fput_many+0x8c/0xdc<br /> [ 214.684230][ C240] fput+0x1c/0xf0<br /> [ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc<br /> [ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140<br /> [ 214.696917][ C240] bio_endio+0x160/0x1bc<br /> [ 214.701001][ C240] blk_update_request+0x1c8/0x3bc<br /> [ 214.705867][ C240] scsi_end_request+0x3c/0x1f0<br /> [ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0<br /> [ 214.715249][ C240] scsi_finish_command+0x104/0x140<br /> [ 214.720200][ C240] scsi_softirq_done+0x90/0x180<br /> [ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70<br /> [ 214.730016][ C240] scsi_mq_done+0x48/0xac<br /> [ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas]<br /> [ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw]<br /> [ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw]<br /> [ 214.752179][ C240] irq_thread_fn+0x34/0xa4<br /> [ 214.756435][ C240] irq_thread+0xc4/0x130<br /> [ 214.760520][ C240] kthread+0x108/0x13c<br /> [ 214.764430][ C240] ret_from_fork+0x10/0x18<br /> <br /> This is because in the hisi_sas driver, both the hardware interrupt<br /> handler and the interrupt thread are executed on the same CPU. In the<br /> performance test scenario, function irq_wait_for_interrupt() will always<br /> return 0 if lots of interrupts occurs and the CPU will be continuously<br /> consumed. As a result, the CPU cannot run the watchdog thread. When the<br /> watchdog time exceeds the specified time, call trace occurs.<br /> <br /> To fix it, add cond_resched() to execute the watchdog thread.