Buggy or mis-configured masters can place bogus logMessageInterval values
in their delay response messages. This patch places reasonable limits on
the range of values that we will accept.
Signed-off-by: Richard Cochran
---
port.c | 16 +++-
1 file changed, 11 insertions(+), 5 deleti
While testing ptp4l with another open source PTP stack (who shall
remain nameless), I found that the foreign master would set the
logMessageInterval field to 0x7F (or 2^127 seconds!) in some
circumstances. Up until now we have trusted this input, but I think
it wiser to enforce some input checking
The logMessageInterval field has an improbable range from 2^-128 to 2^127
seconds. The extreme ends cause an integer overflow in the calculation
of the "foreign master time window". Buggy or mis-configured foreign
masters advertising extreme values will cause incorrect announce message
aging.
Th
---
timemaster.c | 82 ++--
1 file changed, 41 insertions(+), 41 deletions(-)
diff --git a/timemaster.c b/timemaster.c
index 76e48b3..9c71b42 100644
--- a/timemaster.c
+++ b/timemaster.c
@@ -131,7 +131,7 @@ static void extend_string_array(ch
Add wrappers for malloc(), calloc(), realloc() and strdup() that check
if the allocation failed, print an error message and call exit(1). This
allows the caller to use the returned value without checking for errors.
---
util.c | 52
util.h | 37
As per the discussion on linuxptp-users, this is a set that tries to
fix the unhandled errors in memory allocation in timemaster.
Miroslav Lichvar (3):
util: add wrappers for memory allocation functions.
util: exit in string_* and parray_* functions when allocation fails.
timemaster: use wra
---
util.c | 27 +--
util.h | 30 ++
2 files changed, 31 insertions(+), 26 deletions(-)
diff --git a/util.c b/util.c
index 284657b..e7245d6 100644
--- a/util.c
+++ b/util.c
@@ -426,8 +426,10 @@ char *string_newf(const char *format, ...)
On Fri, Aug 28, 2015 at 03:36:23PM +0200, Miroslav Lichvar wrote:
> The new code looks good to me. I did some testing and I see no
> problems. ptp4l/phc2sys/pmc work as expected, valgrind reports no
> errors.
Ok, I'll go ahead push this series out.
(Then, you can add that UDPv6 option you had wan
On Sun, Aug 23, 2015 at 10:05:01PM +0200, Richard Cochran wrote:
> Changes in V5:
> - Add a string type
> - Convert every last option
> - Lightly refactor the pasring code
Awesome!
The new code looks good to me. I did some testing and I see no
problems. ptp4l/phc2sys/pmc work as expected, valgrin