+2
−1
+5
−1
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
When kernel_recvmsg returns -EAGAIN or -ERESTARTSYS, then cifs_demultiplex_thread sleeps for a bit and then tries the read again. When it does this, it's not zeroing out the length and that throws off the value of total_read. Fix it to zero out the length. Can cause memory corruption: If kernel_recvmsg returns an error and total_read is a large enough value, then we'll end up going through the loop again. total_read will be a bogus value, as will (pdu_length-total_read). When this happens we end up calling kernel_recvmsg with a bogus value (possibly larger than the current iov_len). At that point, memcpy_toiovec can overrun iov. It will start walking up the stack, casting other things that are there to struct iovecs (since it assumes that it's been passed an array of them). Any pointer on the stack at an address above the kvec is a candidate for corruption here. Many thanks to Ulrich Obergfell for pointing this out. Signed-off-by:Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE