Re: Potential awk bug?

[Jordan Geoghegan]

On 2020-06-13 05:14, Stuart Henderson wrote:

On 2020-06-12, Jordan Geoghegan  wrote:


On 2020-06-08 11:29, Todd C. Miller wrote:

On Sun, 07 Jun 2020 17:02:03 -0700, Jordan Geoghegan wrote:


Thanks for the quick response. I certainly wasn't expecting to find an
ancient bug like this. Should I be reporting this bug upstream, or are
you planning on upstreaming a diff?

I've created a pull request to fix this upstream:
  https://github.com/onetrueawk/awk/pull/80

   - todd

Sorry for the late reply, I've been AFK for the last week.

Excited to see base system awk get synced with upstream. Kudos to you
and Philip for such a swift and effective response.

btw, note that it's not a direct copy of upstream, OpenBSD's version has
various changes (at least pledge and use of bounded string functions).




Thanks for the info Stuart,  that's awesome, I didn't realise awk was 
pledged. I appreciate the knowledge tidbits you drop from time to time. 
Your bit the other day about having ftp(1) output to stdout to drop all 
filesystem privileges blew my mind and I've subsequently updated most of 
my scripts to take advantage of it.


Regards,

Jordan Geoghegan

Re: Potential awk bug?

[Stuart Henderson]

On 2020-06-12, Jordan Geoghegan  wrote:
>
>
> On 2020-06-08 11:29, Todd C. Miller wrote:
>> On Sun, 07 Jun 2020 17:02:03 -0700, Jordan Geoghegan wrote:
>>
>>> Thanks for the quick response. I certainly wasn't expecting to find an
>>> ancient bug like this. Should I be reporting this bug upstream, or are
>>> you planning on upstreaming a diff?
>> I've created a pull request to fix this upstream:
>>  https://github.com/onetrueawk/awk/pull/80
>>
>>   - todd
>
> Sorry for the late reply, I've been AFK for the last week.
>
> Excited to see base system awk get synced with upstream. Kudos to you 
> and Philip for such a swift and effective response.

btw, note that it's not a direct copy of upstream, OpenBSD's version has
various changes (at least pledge and use of bounded string functions).

Re: Potential awk bug?

[Jordan Geoghegan]

On 2020-06-08 11:29, Todd C. Miller wrote:

On Sun, 07 Jun 2020 17:02:03 -0700, Jordan Geoghegan wrote:


Thanks for the quick response. I certainly wasn't expecting to find an
ancient bug like this. Should I be reporting this bug upstream, or are
you planning on upstreaming a diff?

I've created a pull request to fix this upstream:
 https://github.com/onetrueawk/awk/pull/80

  - todd


Sorry for the late reply, I've been AFK for the last week.

Excited to see base system awk get synced with upstream. Kudos to you 
and Philip for such a swift and effective response.


Regards,

Jordan Geoghegan

Re: Potential awk bug?

[Todd C . Miller]

On Sun, 07 Jun 2020 17:02:03 -0700, Jordan Geoghegan wrote:

> Thanks for the quick response. I certainly wasn't expecting to find an 
> ancient bug like this. Should I be reporting this bug upstream, or are 
> you planning on upstreaming a diff?

I've created a pull request to fix this upstream:
https://github.com/onetrueawk/awk/pull/80

 - todd

Re: Potential awk bug?

[Jordan Geoghegan]

Hi Philip,

Thanks for the quick response. I certainly wasn't expecting to find an 
ancient bug like this. Should I be reporting this bug upstream, or are 
you planning on upstreaming a diff?


Regards,

Jordan



On 2020-06-06 20:16, Philip Guenther wrote:
On Sat, Jun 6, 2020 at 5:08 PM Zé Loff > wrote:


On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> I'm working on a simple awk snippet to convert the IP range data
listed in
> the Extended Delegation Statistics data from ARIN [1] and
convert it into
> CIDR blocks. I have a snippet that works perfectly fine on mawk
and gawk,
> but not on the base system awk. I'm 99% sure I'm not using any
GNUisms, as
> when I break the command up into two parts, it works perfectly.
>
> The snippet below does not work with base awk, but does work
with gawk and
> mawk: (Running on 6.6 -stable system)
>
>   awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US")
printf("%s/%d\n", $4,
> 32-log($5)/log(2))}' delegated-arin-extended-latest.txt
>
>
> The command does output data, but it also throws errors for
certain lines:
>
>   awk: log result out of range
>   input record number 94027, file delegated-arin-extended-latest.txt
>   source line number 1
>
> Most CIDR blocks are calculated correctly, but about 10% of them
have errors
> (ie something that should calculated to be a /24 is instead
calculated to be
> a /30).

...

I have no idea about what is going on, but FWIW I can reproduce
this on
i386 6.7-stable and amd64 6.7-current (well, current-ish, #232).
Truncating the file to a single offending line produces the same
result:
log($5) is out of range.

It appears to have something to do with the last field. Removing it or
changing some of its characters seems to work, e.g.:


arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5e58386636aa775c2106140445cf2c30

arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5a58386636aa775c2106140445cf2c30
                                                    ^
Fails on the first line but works on the second.


Hah!  Nice observation!

The last field of the first line looks kinda like a number in 
scientific notation, but when awk internally tries to set up the 
fields it generates an ERANGE error...and the global errno variable is 
left with that value.  Several builtins in awk, including log(), 
perform operations and then check whether errno is set to EDOM or 
ERANGE but fail to clear errno beforehand.


The fix is to zero errno before all the code sequences that use the 
errcheck() function, ala:


--- run.c       13 Aug 2019 10:45:56 -      1.44
+++ run.c       7 Jun 2020 03:14:38 -
@@ -26,6 +26,7 @@ THIS SOFTWARE.
 #define DEBUG
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1041,8 +1042,10 @@ Cell *arith(Node **a, int n)     /* a[0] + a
        case POWER:
                if (j >= 0 && modf(j, &v) == 0.0)       /* pos integer 
exponent */

                        i = ipow(i, (int) j);
-               else
+               else {
+                       errno = 0;
                        i = errcheck(pow(i, j), "pow");
+               }
                break;
        default:        /* can't happen */
                FATAL("illegal arithmetic operator %d", n);
@@ -1135,8 +1138,10 @@ Cell *assign(Node **a, int n)    /* a[0] =
        case POWEQ:
                if (yf >= 0 && modf(yf, &v) == 0.0)     /* pos integer 
exponent */

                        xf = ipow(xf, (int) yf);
-               else
+               else {
+                       errno = 0;
                        xf = errcheck(pow(xf, yf), "pow");
+               }
                break;
        default:
                FATAL("illegal assignment operator %d", n);
@@ -1499,12 +1504,15 @@ Cell *bltin(Node **a, int n)    /* builtin
                        u = strlen(getsval(x));
                break;
        case FLOG:
+               errno = 0;
                u = errcheck(log(getfval(x)), "log"); break;
        case FINT:
                modf(getfval(x), &u); break;
        case FEXP:
+               errno = 0;
                u = errcheck(exp(getfval(x)), "exp"); break;
        case FSQRT:
+               errno = 0;
                u = errcheck(sqrt(getfval(x)), "sqrt"); break;
        case FSIN:
                u = sin(getfval(x)); break;


Todd, are we up to date with upstream, or is this latent there too?


Philip Guenther

Re: Potential awk bug?

[Todd C . Miller]

On Sat, 06 Jun 2020 18:16:39 -0900, Philip Guenther wrote:

> Todd, are we up to date with upstream, or is this latent there too?

We are not up to date but upstream (https://github.com/onetrueawk/awk)
exhibits the same bug.

 - todd

Re: Potential awk bug?

[Theo de Raadt]

I was halfway there.

That's an old bug.

Philip Guenther  wrote:

> On Sat, Jun 6, 2020 at 5:08 PM Zé Loff  wrote:
> 
> > On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> > > I'm working on a simple awk snippet to convert the IP range data listed
> > in
> > > the Extended Delegation Statistics data from ARIN [1] and convert it into
> > > CIDR blocks. I have a snippet that works perfectly fine on mawk and gawk,
> > > but not on the base system awk. I'm 99% sure I'm not using any GNUisms,
> > as
> > > when I break the command up into two parts, it works perfectly.
> > >
> > > The snippet below does not work with base awk, but does work with gawk
> > and
> > > mawk: (Running on 6.6 -stable system)
> > >
> > >   awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n", $4,
> > > 32-log($5)/log(2))}' delegated-arin-extended-latest.txt
> > >
> > >
> > > The command does output data, but it also throws errors for certain
> > lines:
> > >
> > >   awk: log result out of range
> > >   input record number 94027, file delegated-arin-extended-latest.txt
> > >   source line number 1
> > >
> > > Most CIDR blocks are calculated correctly, but about 10% of them have
> > errors
> > > (ie something that should calculated to be a /24 is instead calculated
> > to be
> > > a /30).
> >
> ...
> 
> > I have no idea about what is going on, but FWIW I can reproduce this on
> > i386 6.7-stable and amd64 6.7-current (well, current-ish, #232).
> > Truncating the file to a single offending line produces the same result:
> > log($5) is out of range.
> >
> > It appears to have something to do with the last field.  Removing it or
> > changing some of its characters seems to work, e.g.:
> >
> >
> > arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5e58386636aa775c2106140445cf2c30
> >
> > arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5a58386636aa775c2106140445cf2c30
> > ^
> > Fails on the first line but works on the second.
> >
> 
> Hah!  Nice observation!
> 
> The last field of the first line looks kinda like a number in scientific
> notation, but when awk internally tries to set up the fields it generates
> an ERANGE error...and the global errno variable is left with that value.
> Several builtins in awk, including log(), perform operations and then check
> whether errno is set to EDOM or ERANGE but fail to clear errno beforehand.
> 
> The fix is to zero errno before all the code sequences that use the
> errcheck() function, ala:
> 
> --- run.c   13 Aug 2019 10:45:56 -  1.44
> +++ run.c   7 Jun 2020 03:14:38 -
> @@ -26,6 +26,7 @@ THIS SOFTWARE.
>  #define DEBUG
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1041,8 +1042,10 @@ Cell *arith(Node **a, int n) /* a[0] + a
> case POWER:
> if (j >= 0 && modf(j, &v) == 0.0)   /* pos integer
> exponent */
> i = ipow(i, (int) j);
> -   else
> +   else {
> +   errno = 0;
> i = errcheck(pow(i, j), "pow");
> +   }
> break;
> default:/* can't happen */
> FATAL("illegal arithmetic operator %d", n);
> @@ -1135,8 +1138,10 @@ Cell *assign(Node **a, int n)/* a[0] =
> case POWEQ:
> if (yf >= 0 && modf(yf, &v) == 0.0) /* pos integer
> exponent */
> xf = ipow(xf, (int) yf);
> -   else
> +   else {
> +   errno = 0;
> xf = errcheck(pow(xf, yf), "pow");
> +   }
> break;
> default:
> FATAL("illegal assignment operator %d", n);
> @@ -1499,12 +1504,15 @@ Cell *bltin(Node **a, int n)/* builtin
> u = strlen(getsval(x));
> break;
> case FLOG:
> +   errno = 0;
> u = errcheck(log(getfval(x)), "log"); break;
> case FINT:
> modf(getfval(x), &u); break;
> case FEXP:
> +   errno = 0;
> u = errcheck(exp(getfval(x)), "exp"); break;
> case FSQRT:
> +   errno = 0;
> u = errcheck(sqrt(getfval(x)), "sqrt"); break;
> case FSIN:
> u = sin(getfval(x)); break;
> 
> 
> Todd, are we up to date with upstream, or is this latent there too?
> 
> 
> Philip Guenther

Re: Potential awk bug?

[Philip Guenther]

On Sat, Jun 6, 2020 at 5:08 PM Zé Loff  wrote:

> On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> > I'm working on a simple awk snippet to convert the IP range data listed
> in
> > the Extended Delegation Statistics data from ARIN [1] and convert it into
> > CIDR blocks. I have a snippet that works perfectly fine on mawk and gawk,
> > but not on the base system awk. I'm 99% sure I'm not using any GNUisms,
> as
> > when I break the command up into two parts, it works perfectly.
> >
> > The snippet below does not work with base awk, but does work with gawk
> and
> > mawk: (Running on 6.6 -stable system)
> >
> >   awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n", $4,
> > 32-log($5)/log(2))}' delegated-arin-extended-latest.txt
> >
> >
> > The command does output data, but it also throws errors for certain
> lines:
> >
> >   awk: log result out of range
> >   input record number 94027, file delegated-arin-extended-latest.txt
> >   source line number 1
> >
> > Most CIDR blocks are calculated correctly, but about 10% of them have
> errors
> > (ie something that should calculated to be a /24 is instead calculated
> to be
> > a /30).
>
...

> I have no idea about what is going on, but FWIW I can reproduce this on
> i386 6.7-stable and amd64 6.7-current (well, current-ish, #232).
> Truncating the file to a single offending line produces the same result:
> log($5) is out of range.
>
> It appears to have something to do with the last field.  Removing it or
> changing some of its characters seems to work, e.g.:
>
>
> arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5e58386636aa775c2106140445cf2c30
>
> arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5a58386636aa775c2106140445cf2c30
> ^
> Fails on the first line but works on the second.
>

Hah!  Nice observation!

The last field of the first line looks kinda like a number in scientific
notation, but when awk internally tries to set up the fields it generates
an ERANGE error...and the global errno variable is left with that value.
Several builtins in awk, including log(), perform operations and then check
whether errno is set to EDOM or ERANGE but fail to clear errno beforehand.

The fix is to zero errno before all the code sequences that use the
errcheck() function, ala:

--- run.c   13 Aug 2019 10:45:56 -  1.44
+++ run.c   7 Jun 2020 03:14:38 -
@@ -26,6 +26,7 @@ THIS SOFTWARE.
 #define DEBUG
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1041,8 +1042,10 @@ Cell *arith(Node **a, int n) /* a[0] + a
case POWER:
if (j >= 0 && modf(j, &v) == 0.0)   /* pos integer
exponent */
i = ipow(i, (int) j);
-   else
+   else {
+   errno = 0;
i = errcheck(pow(i, j), "pow");
+   }
break;
default:/* can't happen */
FATAL("illegal arithmetic operator %d", n);
@@ -1135,8 +1138,10 @@ Cell *assign(Node **a, int n)/* a[0] =
case POWEQ:
if (yf >= 0 && modf(yf, &v) == 0.0) /* pos integer
exponent */
xf = ipow(xf, (int) yf);
-   else
+   else {
+   errno = 0;
xf = errcheck(pow(xf, yf), "pow");
+   }
break;
default:
FATAL("illegal assignment operator %d", n);
@@ -1499,12 +1504,15 @@ Cell *bltin(Node **a, int n)/* builtin
u = strlen(getsval(x));
break;
case FLOG:
+   errno = 0;
u = errcheck(log(getfval(x)), "log"); break;
case FINT:
modf(getfval(x), &u); break;
case FEXP:
+   errno = 0;
u = errcheck(exp(getfval(x)), "exp"); break;
case FSQRT:
+   errno = 0;
u = errcheck(sqrt(getfval(x)), "sqrt"); break;
case FSIN:
u = sin(getfval(x)); break;


Todd, are we up to date with upstream, or is this latent there too?


Philip Guenther

Re: Potential awk bug?

[Zé Loff]

On Sat, Jun 06, 2020 at 03:51:58PM -0700, Jordan Geoghegan wrote:
> Hello,
> 
> I was hoping the fine folks here could give me a quick sanity check, I'm by
> no means an awk guru, so I'm likely missing something obvious. I wanted to
> ask here quickly before I started flapping my gums on bugs@.
> 
> I'm working on a simple awk snippet to convert the IP range data listed in
> the Extended Delegation Statistics data from ARIN [1] and convert it into
> CIDR blocks. I have a snippet that works perfectly fine on mawk and gawk,
> but not on the base system awk. I'm 99% sure I'm not using any GNUisms, as
> when I break the command up into two parts, it works perfectly.
> 
> The snippet below does not work with base awk, but does work with gawk and
> mawk: (Running on 6.6 -stable system)
> 
>   awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n", $4,
> 32-log($5)/log(2))}' delegated-arin-extended-latest.txt
> 
> 
> The command does output data, but it also throws errors for certain lines:
> 
>   awk: log result out of range
>   input record number 94027, file delegated-arin-extended-latest.txt
>   source line number 1
> 
> Most CIDR blocks are calculated correctly, but about 10% of them have errors
> (ie something that should calculated to be a /24 is instead calculated to be
> a /30).
> 
> However, when I break it up into two parts, it produces the expected output:
> 
>   awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") print($4, $5)}'
> delegated-arin-extended-latest.txt | awk  '{printf("%s/%d\n", $1,
> 32-log($2)/log(2)) }'
> 
> As you can see, the same number of lines are printed, but the hashes are
> different.
> 
>   luna$ gawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n",
> $4, 32-log($5)/log(2))}' delegated-*-latest.txt | wc -l
>      56446
>   luna$ mawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n",
> $4, 32-log($5)/log(2))}' delegated-*-latest.txt | wc -l
>      56446
>   luna$ awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n", $4,
> 32-log($5)/log(2))}' delegated-*-latest.txt 2>/dev/null | wc -l
>      56446
> 
>   luna$ awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n", $4,
> 32-log($5)/log(2))}' delegated-arin-extended-latest.txt 2>/dev/null | md5
>     6f549bbc0799bc202c12695f8530d1df
>   luna$ gawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n",
> $4, 32-log($5)/log(2))}' delegated-arin-extended-latest.txt 2>/dev/null |
> md5
>     40c28b8ebfd2796e1ae15d9f6401c0c1
>   luna$ mawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n",
> $4, 32-log($5)/log(2))}' delegated-arin-extended-latest.txt 2>/dev/null |
> md5
>     40c28b8ebfd2796e1ae15d9f6401c0c1
> 
> 
> Example of the differences:
> 
> --- mawk.txt    Sat Jun  6 18:43:30 2020
> +++ awk.txt Sat Jun  6 18:43:38 2020
> @@ -29,7 +29,7 @@
>  9.64.0.0/10
>  9.128.0.0/9
>  11.0.0.0/8
> -12.0.0.0/8
> +12.0.0.0/30
>  13.0.0.0/11
>  13.32.0.0/12
>  13.48.0.0/14
> @@ -415,7 +415,7 @@
>  23.90.64.0/20
>  23.90.80.0/21
>  23.90.88.0/22
> -23.90.92.0/22
> +23.90.92.0/30
>  23.90.96.0/19
>  23.91.0.0/19
>  23.91.32.0/19
> @@ -545,8 +545,8 @@
>  23.133.224.0/24
>  23.133.240.0/24
>  23.134.0.0/24
> -23.134.16.0/24
> -23.134.17.0/24
> +23.134.16.0/30
> +23.134.17.0/30
> 
> 
> Any insight or advice would be much appreciated.
> 
> Regards,
> 
> Jordan
> 
> [1] https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest
> 
> 

I have no idea about what is going on, but FWIW I can reproduce this on
i386 6.7-stable and amd64 6.7-current (well, current-ish, #232).
Truncating the file to a single offending line produces the same result:
log($5) is out of range.

It appears to have something to do with the last field.  Removing it or
changing some of its characters seems to work, e.g.:

arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5e58386636aa775c2106140445cf2c30
arin|US|ipv4|216.250.144.0|4096|20050503|allocated|5a58386636aa775c2106140445cf2c30
^
Fails on the first line but works on the second.

-- 
 

Potential awk bug?

[Jordan Geoghegan]

Hello,

I was hoping the fine folks here could give me a quick sanity check, I'm 
by no means an awk guru, so I'm likely missing something obvious. I 
wanted to ask here quickly before I started flapping my gums on bugs@.


I'm working on a simple awk snippet to convert the IP range data listed 
in the Extended Delegation Statistics data from ARIN [1] and convert it 
into CIDR blocks. I have a snippet that works perfectly fine on mawk and 
gawk, but not on the base system awk. I'm 99% sure I'm not using any 
GNUisms, as when I break the command up into two parts, it works perfectly.


The snippet below does not work with base awk, but does work with gawk 
and mawk: (Running on 6.6 -stable system)


  awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") printf("%s/%d\n", $4, 
32-log($5)/log(2))}' delegated-arin-extended-latest.txt



The command does output data, but it also throws errors for certain lines:

  awk: log result out of range
  input record number 94027, file delegated-arin-extended-latest.txt
  source line number 1

Most CIDR blocks are calculated correctly, but about 10% of them have 
errors (ie something that should calculated to be a /24 is instead 
calculated to be a /30).


However, when I break it up into two parts, it produces the expected output:

  awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") print($4, $5)}' 
delegated-arin-extended-latest.txt | awk  '{printf("%s/%d\n", $1, 
32-log($2)/log(2)) }'


As you can see, the same number of lines are printed, but the hashes are 
different.


  luna$ gawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") 
printf("%s/%d\n", $4, 32-log($5)/log(2))}' delegated-*-latest.txt | wc -l

     56446
  luna$ mawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") 
printf("%s/%d\n", $4, 32-log($5)/log(2))}' delegated-*-latest.txt | wc -l

     56446
  luna$ awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") 
printf("%s/%d\n", $4, 32-log($5)/log(2))}' delegated-*-latest.txt 
2>/dev/null | wc -l

     56446

  luna$ awk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") 
printf("%s/%d\n", $4, 32-log($5)/log(2))}' 
delegated-arin-extended-latest.txt 2>/dev/null | md5

    6f549bbc0799bc202c12695f8530d1df
  luna$ gawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") 
printf("%s/%d\n", $4, 32-log($5)/log(2))}' 
delegated-arin-extended-latest.txt 2>/dev/null | md5

    40c28b8ebfd2796e1ae15d9f6401c0c1
  luna$ mawk -F '|' '{ if ( $3 == "ipv4" && $2 == "US") 
printf("%s/%d\n", $4, 32-log($5)/log(2))}' 
delegated-arin-extended-latest.txt 2>/dev/null | md5

    40c28b8ebfd2796e1ae15d9f6401c0c1


Example of the differences:

--- mawk.txt    Sat Jun  6 18:43:30 2020
+++ awk.txt Sat Jun  6 18:43:38 2020
@@ -29,7 +29,7 @@
 9.64.0.0/10
 9.128.0.0/9
 11.0.0.0/8
-12.0.0.0/8
+12.0.0.0/30
 13.0.0.0/11
 13.32.0.0/12
 13.48.0.0/14
@@ -415,7 +415,7 @@
 23.90.64.0/20
 23.90.80.0/21
 23.90.88.0/22
-23.90.92.0/22
+23.90.92.0/30
 23.90.96.0/19
 23.91.0.0/19
 23.91.32.0/19
@@ -545,8 +545,8 @@
 23.133.224.0/24
 23.133.240.0/24
 23.134.0.0/24
-23.134.16.0/24
-23.134.17.0/24
+23.134.16.0/30
+23.134.17.0/30


Any insight or advice would be much appreciated.

Regards,

Jordan

[1] https://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest