Summary: | The fix for glibc y2038 may have a mechanism bug. | ||
---|---|---|---|
Product: | glibc | Reporter: | nixiaoming <nixiaoming> |
Component: | time | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED NOTABUG | ||
Severity: | normal | CC: | adhemerval.zanella |
Priority: | P2 | ||
Version: | 2.36 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
nixiaoming
2022-04-22 06:55:02 UTC
(In reply to nixiaoming from comment #0) > Y2038 issue: Use 32-bit timestamps to store, overflow occurs in 2038. > To fix the Y2038 issue, the 64-bit save time needs to be used. A large > number of system calls are added to the corresponding community, > However, to ensure compatibility, the original interface still exists, > > In the Y2038 patch , the modification scheme for these original interfaces > is as follows: > Step 1: Convert 32-bit data to 64-bit data. > Step 2: Invoke the new system call (64-bit). > Step 3: Convert the returned data into 32-bit data. > > This function is normal in normal scenarios. > However, there is a bug in the case of abnormal input. > > case 1: the input address is unreadable and an expected failure is returned. > However, in step 1, SIG11 is triggered and the program crashes. > Case 2: The input address is unwritable and an expected failure is returned. > However, in step 3, SIG11 is triggered and the program crashes. This is similar to BZ#27662, where as Andreas Schwab has put, it is undefined behavior. Different than kernel, we don't have a reliable way to generate EFAULT in userland (not without a lot of hacks that it is outside the glibc scope). A valid issue with the interface is where the contract that state the input *might* be NULL. In this case, it is invalid the glibc wrapper to assume pointer validity and thus need to handle it (for instance, the timeout input on select). So as for BZ#27662 I will close this bug a NOTABUG. Would it be better to add __nonnull to the function declaration? Like this: -extern int __adjtimex (struct timex *__ntx); +extern int __adjtimex (struct timex *__ntx) __nonnull ((1)); (In reply to nixiaoming from comment #2) > Would it be better to add __nonnull to the function declaration? > > Like this: > > -extern int __adjtimex (struct timex *__ntx); > +extern int __adjtimex (struct timex *__ntx) __nonnull ((1)); Yes, this will be a good improvement. There are multiple interfaces that might be improved with the annotation. |