netdev - Fw: [Bug 216986] New: sendmsg returns EINVAL when neighbor table is full

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Tue, 31 Jan 2023 19:07:45 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     netdev@...r.kernel.org
Subject: Fw: [Bug 216986] New: sendmsg returns EINVAL when neighbor table is
 full

Begin forwarded message:

Date: Wed, 01 Feb 2023 02:21:14 +0000
From: bugzilla-daemon@...nel.org
To: stephen@...workplumber.org
Subject: [Bug 216986] New: sendmsg returns EINVAL when neighbor table is full

https://bugzilla.kernel.org/show_bug.cgi?id=216986

            Bug ID: 216986
           Summary: sendmsg returns EINVAL when neighbor table is full
           Product: Networking
           Version: 2.5
    Kernel Version: 5.2.60
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: IPV4
          Assignee: stephen@...workplumber.org
          Reporter: singhpra@...iper.net
        Regression: No

On one of our linux boxes, we happen to hit the
net.ipv4.neigh.default.gc_thresh3
limit and saw "neighbour: arp_cache: neighbor table overflow! ".

Subsequent to this, we saw EINVAL error for some of the applications that were
trying to do a sendmsg. The applications treats the EINVAL error as fatal
(especially when sendmsg was working with the same set of ARGS earlier on the
system).

The question here is should the kernel neighbor table state result in an error
like EINVAL for the application where the arguments provided by the application
looks valid and have been working so far. Is there any other reason that
justifies the EINVAL returned for this case by kernel?

Looking further into the code it seems like in the function ip_finish_output2,
even on the latest kernel, post the checks for neighbor entry, the status of
ip_neigh_for_gw for error is not used, which in this case would be ENOBUFS and
I would think could also be a possible alternative to return here instead of
EINVAL at the end of the function. 

ip_finish_output2:
        neigh = ip_neigh_for_gw(rt, skb, &is_v6gw);  
                    if (!IS_ERR(neigh)) {
                   …
               }                                                                
        ==>perhaps can return this neigh if IS_ERR is true  
        net_dbg_ratelimited("%s: No header cache and no neighbour!\n",
                                                                 __func__);
        kfree_skb_reason(skb, SKB_DROP_REASON_NEIGH_CREATEFAIL);
        return -EINVAL;==> here

___neigh_create:
        n = neigh_alloc(tbl, dev, flags, exempt_from_gc);
        trace_neigh_create(tbl, dev, pkey, n, exempt_from_gc);
        if (!n) {
                rc = ERR_PTR(-ENOBUFS); ==> returns ENOBUFS
                goto out;
        }

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.