Windows Kernel Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2023-21675, CVE-2023-21748, CVE-2023-21749, CVE-2023-21750, CVE-2023-21754, CVE-2023-21755, CVE-2023-21772, CVE-2023-21773, CVE-2023-21774.

CVE-2023-21747

Windows Kernel Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2023-21747, CVE-2023-21748, CVE-2023-21749, CVE-2023-21750, CVE-2023-21754, CVE-2023-21755, CVE-2023-21772, CVE-2023-21773, CVE-2023-21774.

CVE-2023-21675

Windows Lightweight Directory Access Protocol (LDAP) Denial of Service Vulnerability.

CVE-2023-21557

Windows Credential Manager User Interface Elevation of Privilege Vulnerability.

CVE-2023-21726

Windows Advanced Local Procedure Call (ALPC) Elevation of Privilege Vulnerability.

CVE-2023-21674

Windows Kernel Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2023-21675, CVE-2023-21747, CVE-2023-21748, CVE-2023-21749, CVE-2023-21754, CVE-2023-21755, CVE-2023-21772, CVE-2023-21773, CVE-2023-21774.

CVE-2023-21750

Windows Kernel Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2023-21675, CVE-2023-21747, CVE-2023-21748, CVE-2023-21750, CVE-2023-21754, CVE-2023-21755, CVE-2023-21772, CVE-2023-21773, CVE-2023-21774.

CVE-2023-21749

Windows Kernel Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2023-21675, CVE-2023-21747, CVE-2023-21749, CVE-2023-21750, CVE-2023-21754, CVE-2023-21755, CVE-2023-21772, CVE-2023-21773, CVE-2023-21774.

CVE-2023-21748

An out-of-bounds read in Organization Specific TLV was found in various versions of OpenvSwitch.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[<thread-prev\] \[day\] \[month\] \[year\] \[list\]

Date: Wed, 21 Dec 2022 12:10:03 +0100
From: Ilya Maximets <i.maximets@....org>
To: oss-security@...ts.openwall.com, ovs-announce@...nvswitch.org,
 ovs-discuss <ovs-discuss@...nvswitch.org>
Cc: i.maximets@....org, Aaron Conole <aconole@...hat.com>,
 Qian Chen <cq674350529@...il.com>, John Helmert III <ajak@...too.org>
Subject: Re: \[ADVISORY\] LLDP underflow while parsing malformed Auto Attach TLV
 (Open vSwitch)

On 12/20/22 22:39, Ilya Maximets wrote:
> Description
> ===========
> 
> Multiple versions of Open vSwitch are vulnerable to crafted LLDP
> packets causing denial of service, and data underflow attacks.
> Triggering the vulnerabilities requires LLDP processing to be enabled
> for a specific port.  Open vSwitch versions prior to 2.4.0 are not
> vulnerable.
> 
> The Common Vulnerabilities and Exposures project (cve.mitre.org)
> did not assign the identifier to this issue yet.  The identifier will
> be communicated separately.

Following CVE identifiers have been allocated for the issue (one per
TLV type since they can have a slightly different effect):

 - CVE-2022-4337 for Out-of-Bounds Read in Organization Specific TLV
 - CVE-2022-4338 for Integer Underflow in Organization Specific TLV

The fix referenced in this advisory covers both issues.

> This issue does not affect the \`lldpd'
> project, although they share a code base.  The issue is related to
> parsing the Auto Attach TLVs, which is specific to the Open vSwitch
> implementation.
> 
> 
> Mitigation
> ==========
> 
> For any version of Open vSwitch, preventing LLDP packets from reaching
> Open vSwitch mitigates the vulnerability.  We do not recommend
> attempting to mitigate the vulnerability this way because of the
> following difficulties:
> 
>     - Open vSwitch obtains packets before the iptables host firewall,
>       so ebtables on the Open vSwitch host cannot ordinarily block the
>       vulnerability.
> 
>     - If Open vSwitch is configured to receive and transmit LLDP
>       messages, the required functionality will need to be disabled
>       potentially disrupting the network.
> 
> We have found that Open vSwitch is subject to a denial of service, and
> possibly a remote code execution exploit when LLDP processing is enabled
> on an interface.  By default, interfaces are not configured to process
> LLDP messages.
> 
> 
> Fix
> ===
> 
> Patches to fix these vulnerabilities in Open vSwitch 2.13.x and newer are
> applied to the appropriate branches, and the original patch is located
> at:
> 
>    https://mail.openvswitch.org/pipermail/ovs-dev/2022-December/400596.html
> 
> Recommendation
> ==============
> 
> We recommend that users of Open vSwitch apply the respective patch, or
> upgrade to a known patched version of Open vSwitch.  These include:
> 
> \* 3.0.3
> \* 2.17.5
> \* 2.16.6
> \* 2.15.7
> \* 2.14.8
> \* 2.13.10
> 
> 
> Acknowledgments
> ===============
> 
> The Open vSwitch team wishes to thank the reporter:
> 
>   Qian Chen <cq674350529@...il.com>
> 

**Download attachment "**OpenPGP\_0xB9F7EC77C829BF96.asc**" of type "**application/pgp-keys**" (4740 bytes)**

**Download attachment "**OpenPGP\_signature**" of type "**application/pgp-signature**" (841 bytes)**

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

CVE-2022-4337: security - Re: [ADVISORY] LLDP underflow while parsing malformed Auto Attach TLV (Open vSwitch)

A use-after-free flaw caused by a race among the superblock operations in the gadgetfs Linux driver was found. It could be triggered by yanking out a device that is running the gadgetfs side.

*   Products
    *   Openwall GNU/\*/Linux   _server OS_
    *   Linux Kernel Runtime Guard
    *   John the Ripper   _password cracker_
        *   Free & Open Source for any platform
        *   in the cloud
        *   Pro for Linux
        *   Pro for macOS
    *   Wordlists   _for password cracking_
    *   passwdqc   _policy enforcement_
        *   Free & Open Source for Unix
        *   Pro for Windows (Active Directory)
    *   yescrypt   _KDF & password hashing_
    *   yespower   _Proof-of-Work (PoW)_
    *   crypt\_blowfish   _password hashing_
    *   phpass   _ditto in PHP_
    *   tcb   _better password shadowing_
    *   Pluggable Authentication Modules
    *   scanlogd   _port scan detector_
    *   popa3d   _tiny POP3 daemon_
    *   blists   _web interface to mailing lists_
    *   msulogin   _single user mode login_
    *   php\_mt\_seed   _mt\_rand() cracker_
*   Services
*   Publications
    *   Articles
    *   Presentations
*   Resources
    *   Mailing lists
    *   Community wiki
    *   Source code repositories (GitHub)
    *   Source code repositories (CVSweb)
    *   File archive & mirrors
    *   How to verify digital signatures
    *   OVE IDs
*   What's new

\[<prev\] \[next>\] \[<thread-prev\] \[day\] \[month\] \[year\] \[list\]

Date: Wed, 14 Dec 2022 23:22:38 +0800
From: Gerald Lee <sundaywind2004@...il.com>
To: oss-security@...ts.openwall.com
Subject: Re: Linux Kernel: usb: A use-after-free Write in put\_dev

This was assigned CVE-2022-4382.

=\*=\*=\*=\*=\*=\*=\*=\*=     CREDIT     =\*=\*=\*=\*=\*=\*=\*=\*=

Zhixin Li from Zero-one Security <sundaywind2004@...il.com>


Thanks.


On Tue, Dec 13, 2022 at 2:53 PM Gerald Lee <sundaywind2004@...il.com> wrote:
>
> Hi all,
>
> =\*=\*=\*=\*=\*=\*=\*=\*=   BUG DETAILS  =\*=\*=\*=\*=\*=\*=\*=\*=
>
> This use-after-free violation is caused by a race among the superblock
> operations in the gadgetfs driver. The vulnerability may not be a big
> deal, because the normal user can't execute umount. It could be
> triggered by yanking out a device that is running the gadgetfs side,
> but I don't know how to do that.
>
> C repro is attached.
>
> =\*=\*=\*=\*=\*=\*=\*=\*=     BACKTRACE     =\*=\*=\*=\*=\*=\*=\*=\*=
> BUG: KASAN: use-after-free in instrument\_atomic\_read\_write
> include/linux/instrumented.h:102 \[inline\]
> BUG: KASAN: use-after-free in atomic\_fetch\_sub\_release
> include/linux/atomic/atomic-instrumented.h:176 \[inline\]
> BUG: KASAN: use-after-free in \_\_refcount\_sub\_and\_test
> include/linux/refcount.h:272 \[inline\]
> BUG: KASAN: use-after-free in \_\_refcount\_dec\_and\_test
> include/linux/refcount.h:315 \[inline\]
> BUG: KASAN: use-after-free in refcount\_dec\_and\_test
> include/linux/refcount.h:333 \[inline\]
> BUG: KASAN: use-after-free in put\_dev+0x22/0xd0
> drivers/usb/gadget/legacy/inode.c:159
> Write of size 4 at addr ffff8880436d2040 by task syz-executor.5/7587
>
> CPU: 1 PID: 7587 Comm: syz-executor.5 Not tainted 6.1.0-rc7 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.13.0-1ubuntu1.1 04/01/2014
> Call Trace:
>  <TASK>
>  \_\_dump\_stack lib/dump\_stack.c:88 \[inline\]
>  dump\_stack\_lvl+0xd1/0x138 lib/dump\_stack.c:106
>  print\_address\_description mm/kasan/report.c:284 \[inline\]
>  print\_report+0x15e/0x45d mm/kasan/report.c:395
>  kasan\_report+0xbf/0x1f0 mm/kasan/report.c:495
>  check\_region\_inline mm/kasan/generic.c:183 \[inline\]
>  kasan\_check\_range+0x141/0x190 mm/kasan/generic.c:189
>  instrument\_atomic\_read\_write include/linux/instrumented.h:102 \[inline\]
>  atomic\_fetch\_sub\_release
> include/linux/atomic/atomic-instrumented.h:176 \[inline\]
>  \_\_refcount\_sub\_and\_test include/linux/refcount.h:272 \[inline\]
>  \_\_refcount\_dec\_and\_test include/linux/refcount.h:315 \[inline\]
>  refcount\_dec\_and\_test include/linux/refcount.h:333 \[inline\]
>  put\_dev+0x22/0xd0 drivers/usb/gadget/legacy/inode.c:159
>  gadgetfs\_kill\_sb+0x2e/0x60 drivers/usb/gadget/legacy/inode.c:2086
>  deactivate\_locked\_super+0x98/0x160 fs/super.c:332
>  vfs\_get\_super fs/super.c:1190 \[inline\]
>  get\_tree\_single+0x188/0x1d0 fs/super.c:1207
>  vfs\_get\_tree+0x8d/0x2f0 fs/super.c:1531
>  vfs\_fsconfig\_locked fs/fsopen.c:232 \[inline\]
>  \_\_do\_sys\_fsconfig+0x8d6/0xc20 fs/fsopen.c:439
>  do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
>  do\_syscall\_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
> RIP: 0033:0x7f8d5129078d
> Code: c3 e8 17 32 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 48
> 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
> 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f8d52024bd8 EFLAGS: 00000246 ORIG\_RAX: 00000000000001af
> RAX: ffffffffffffffda RBX: 00007f8d513cbf80 RCX: 00007f8d5129078d
> RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003
> RBP: 00007f8d512feb02 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> R13: 00007ffd48293eff R14: 00007ffd48294090 R15: 00007f8d52024d80
>  </TASK>
>
> Allocated by task 7561:
>  kasan\_save\_stack+0x22/0x40 mm/kasan/common.c:45
>  kasan\_set\_track+0x25/0x30 mm/kasan/common.c:52
>  \_\_\_\_kasan\_kmalloc mm/kasan/common.c:371 \[inline\]
>  \_\_\_\_kasan\_kmalloc mm/kasan/common.c:330 \[inline\]
>  \_\_kasan\_kmalloc+0xa5/0xb0 mm/kasan/common.c:380
>  kmalloc include/linux/slab.h:553 \[inline\]
>  kzalloc include/linux/slab.h:689 \[inline\]
>  dev\_new drivers/usb/gadget/legacy/inode.c:170 \[inline\]
>  gadgetfs\_fill\_super+0x1e4/0x460 drivers/usb/gadget/legacy/inode.c:2041
>  vfs\_get\_super fs/super.c:1169 \[inline\]
>  get\_tree\_single+0xd6/0x1d0 fs/super.c:1207
>  vfs\_get\_tree+0x8d/0x2f0 fs/super.c:1531
>  vfs\_fsconfig\_locked fs/fsopen.c:232 \[inline\]
>  \_\_do\_sys\_fsconfig+0x8d6/0xc20 fs/fsopen.c:439
>  do\_syscall\_x64 arch/x86/entry/common.c:50 \[inline\]
>  do\_syscall\_64+0x39/0xb0 arch/x86/entry/common.c:80
>  entry\_SYSCALL\_64\_after\_hwframe+0x63/0xcd
>
> Last potentially related work creation:
>  kasan\_save\_stack+0x22/0x40 mm/kasan/common.c:45
>  \_\_kasan\_record\_aux\_stack+0xbc/0xd0 mm/kasan/generic.c:481
>  call\_rcu+0x9d/0x820 kernel/rcu/tree.c:2798
>  pwq\_unbound\_release\_workfn+0x26b/0x340 kernel/workqueue.c:3736
>  process\_one\_work+0x9bf/0x1710 kernel/workqueue.c:2289
>  worker\_thread+0x669/0x1090 kernel/workqueue.c:2436
>  kthread+0x2e8/0x3a0 kernel/kthread.c:376
>  ret\_from\_fork+0x1f/0x30 arch/x86/entry/entry\_64.S:306
>
> Second to last potentially related work creation:
>  kasan\_save\_stack+0x22/0x40 mm/kasan/common.c:45
>  \_\_kasan\_record\_aux\_stack+0xbc/0xd0 mm/kasan/generic.c:481
>  call\_rcu+0x9d/0x820 kernel/rcu/tree.c:2798
>  pwq\_unbound\_release\_workfn+0x26b/0x340 kernel/workqueue.c:3736
>  process\_one\_work+0x9bf/0x1710 kernel/workqueue.c:2289
>  worker\_thread+0x669/0x1090 kernel/workqueue.c:2436
>  kthread+0x2e8/0x3a0 kernel/kthread.c:376
>  ret\_from\_fork+0x1f/0x30 arch/x86/entry/entry\_64.S:306
>
> The buggy address belongs to the object at ffff8880436d2000
>  which belongs to the cache kmalloc-1k of size 1024
> The buggy address is located 64 bytes inside of
>  1024-byte region \[ffff8880436d2000, ffff8880436d2400)
>
> The buggy address belongs to the physical page:
> page:ffffea00010db400 refcount:1 mapcount:0 mapping:0000000000000000
> index:0x0 pfn:0x436d0
> head:ffffea00010db400 order:3 compound\_mapcount:0 compound\_pincount:0
> flags: 0x4fff00000010200(slab|head|node=1|zone=1|lastcpupid=0x7ff)
> raw: 04fff00000010200 dead000000000100 dead000000000122 ffff888012041dc0
> raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page\_owner tracks the page as allocated
> page last allocated via order 3, migratetype Unmovable, gfp\_mask
> 0x52a20(GFP\_ATOMIC|\_\_GFP\_NOWARN|\_\_GFP\_NORETRY|\_\_GFP\_COMP), pid 6599,
> tgid 6599 (syz-executor.0), ts 29294571719, free\_ts 29285126043
>  prep\_new\_page mm/page\_alloc.c:2539 \[inline\]
>  get\_page\_from\_freelist+0x10b5/0x2d50 mm/page\_alloc.c:4291
>  \_\_alloc\_pages+0x1cb/0x5b0 mm/page\_alloc.c:5558
>  alloc\_pages+0x1aa/0x270 mm/mempolicy.c:2285
>  alloc\_slab\_page mm/slub.c:1794 \[inline\]
>  allocate\_slab+0x213/0x300 mm/slub.c:1939
>  new\_slab mm/slub.c:1992 \[inline\]
>  \_\_\_slab\_alloc+0xa9b/0x13e0 mm/slub.c:3180
>  \_\_slab\_alloc.constprop.0+0x56/0xa0 mm/slub.c:3279
>  slab\_alloc\_node mm/slub.c:3364 \[inline\]
>  \_\_kmem\_cache\_alloc\_node+0x199/0x3e0 mm/slub.c:3437
>  kmalloc\_trace+0x26/0x60 mm/slab\_common.c:1045
>  kmalloc include/linux/slab.h:553 \[inline\]
>  kzalloc include/linux/slab.h:689 \[inline\]
>  batadv\_hardif\_add\_interface net/batman-adv/hard-interface.c:864 \[inline\]
>  batadv\_hard\_if\_event+0x8a1/0x1450 net/batman-adv/hard-interface.c:952
>  notifier\_call\_chain+0xb5/0x200 kernel/notifier.c:87
>  call\_netdevice\_notifiers\_info+0xb5/0x130 net/core/dev.c:1945
>  call\_netdevice\_notifiers\_extack net/core/dev.c:1983 \[inline\]
>  call\_netdevice\_notifiers net/core/dev.c:1997 \[inline\]
>  register\_netdevice+0x10bf/0x1670 net/core/dev.c:10090
>  veth\_newlink+0x4d1/0x990 drivers/net/veth.c:1795
>  rtnl\_newlink\_create net/core/rtnetlink.c:3364 \[inline\]
>  \_\_rtnl\_newlink+0x1084/0x17e0 net/core/rtnetlink.c:3581
>  rtnl\_newlink+0x68/0xa0 net/core/rtnetlink.c:3594
>  rtnetlink\_rcv\_msg+0x43e/0xca0 net/core/rtnetlink.c:6091
> page last free stack trace:
>  reset\_page\_owner include/linux/page\_owner.h:24 \[inline\]
>  free\_pages\_prepare mm/page\_alloc.c:1459 \[inline\]
>  free\_pcp\_prepare+0x65c/0xd90 mm/page\_alloc.c:1509
>  free\_unref\_page\_prepare mm/page\_alloc.c:3387 \[inline\]
>  free\_unref\_page+0x1d/0x4d0 mm/page\_alloc.c:3483
>  qlink\_free mm/kasan/quarantine.c:168 \[inline\]
>  qlist\_free\_all+0x6a/0x170 mm/kasan/quarantine.c:187
>  kasan\_quarantine\_reduce+0x184/0x210 mm/kasan/quarantine.c:294
>  \_\_kasan\_slab\_alloc+0x66/0x90 mm/kasan/common.c:302
>  kasan\_slab\_alloc include/linux/kasan.h:201 \[inline\]
>  slab\_post\_alloc\_hook mm/slab.h:737 \[inline\]
>  slab\_alloc\_node mm/slub.c:3398 \[inline\]
>  \_\_kmem\_cache\_alloc\_node+0x2e2/0x3e0 mm/slub.c:3437
>  kmalloc\_trace+0x26/0x60 mm/slab\_common.c:1045
>  kmalloc include/linux/slab.h:553 \[inline\]
>  kzalloc include/linux/slab.h:689 \[inline\]
>  kset\_create lib/kobject.c:937 \[inline\]
>  kset\_create\_and\_add+0x4f/0x1a0 lib/kobject.c:980
>  register\_queue\_kobjects net/core/net-sysfs.c:1766 \[inline\]
>  netdev\_register\_kobject+0x1ca/0x400 net/core/net-sysfs.c:2019
>  register\_netdevice+0xd99/0x1670 net/core/dev.c:10057
>  \_\_ip\_tunnel\_create+0x398/0x570 net/ipv4/ip\_tunnel.c:267
>  ip\_tunnel\_init\_net+0x2ec/0x9f0 net/ipv4/ip\_tunnel.c:1073
>  ops\_init+0xb9/0x680 net/core/net\_namespace.c:135
>  setup\_net+0x5d1/0xc50 net/core/net\_namespace.c:332
>  copy\_net\_ns+0x31c/0x760 net/core/net\_namespace.c:478
>  create\_new\_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110
>
> Memory state around the buggy address:
>  ffff8880436d1f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  ffff8880436d1f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >ffff8880436d2000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>                                            ^
>  ffff8880436d2080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  ffff8880436d2100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> =\*=\*=\*=\*=\*=\*=\*=\*=     PATCH     =\*=\*=\*=\*=\*=\*=\*=\*=
>
> The patch has been done by Alan Stern, and it can be found here:
> https://lore.kernel.org/linux-usb/Y5dV11OoM3ojxNHy@rowland.harvard.edu/
>
> Thanks.

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.

Tag

#windows