OESA-2024-2152

Source
https://www.openeuler.org/en/security/security-bulletins/detail/?id=openEuler-SA-2024-2152
Import Source
https://repo.openeuler.org/security/data/osv/OESA-2024-2152.json
JSON Data
https://api.test.osv.dev/v1/vulns/OESA-2024-2152
Upstream
Published
2024-09-20T11:09:10Z
Modified
2025-08-12T05:40:11.689436Z
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035i2cmaster_xfer

In af9035i2cmasterxfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9035i2cmasterxfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.

Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027i2cxfer()")(CVE-2023-52915)

In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: core: Check for unset descriptor

Make sure the descriptor has been set before looking at maxpacket. This fixes a null pointer panic in this case.

This may happen if the gadget doesn't properly set up the endpoint for the current speed, or the gadget descriptors are malformed and the descriptor for the speed/endpoint are not found.

No current gadget driver is known to have this problem, but this may cause a hard-to-find bug during development of new gadgets.(CVE-2024-44960)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: prevent UAF in ip6sendskb()

syzbot reported an UAF in ip6sendskb() [1]

After ip6localout() has returned, we no longer can safely dereference rt, unless we hold rcureadlock().

A similar issue has been fixed in commit a688caa34beb ("ipv6: take rcu lock in rawv6sendhdrinc()")

Another potential issue in ip6finishoutput2() is handled in a separate patch.

[1] BUG: KASAN: slab-use-after-free in ip6sendskb+0x18d/0x230 net/ipv6/ip6_output.c:1964 Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530

CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:93 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:119 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 ip6sendskb+0x18d/0x230 net/ipv6/ip6output.c:1964 rawv6pushpendingframes+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x1a6/0x270 net/socket.c:745 sockwriteiter+0x2dd/0x400 net/socket.c:1160 doiterreadvwritev+0x60a/0x890 vfswritev+0x37c/0xbb0 fs/readwrite.c:971 dowritev+0x1b1/0x350 fs/readwrite.c:1018 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f936bf79e79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014 RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79 RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004 RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 </TASK>

Allocated by task 6530: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 unpoisonslabobject mm/kasan/common.c:312 [inline] kasanslaballoc+0x66/0x80 mm/kasan/common.c:338 kasanslaballoc include/linux/kasan.h:201 [inline] slabpostallochook mm/slub.c:3988 [inline] slaballocnode mm/slub.c:4037 [inline] kmemcacheallocnoprof+0x135/0x2a0 mm/slub.c:4044 dstalloc+0x12b/0x190 net/core/dst.c:89 ip6blackholeroute+0x59/0x340 net/ipv6/route.c:2670 makeblackhole net/xfrm/xfrmpolicy.c:3120 [inline] xfrmlookuproute+0xd1/0x1c0 net/xfrm/xfrmpolicy.c:3313 ip6dstlookupflow+0x13e/0x180 net/ipv6/ip6output.c:1257 rawv6sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 socksendmsgnosec net/socket.c:730 [inline] _socksendmsg+0x1a6/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2597 _syssendmsg net/socket.c:2651 [inline] _syssendmsg+0x2b0/0x3a0 net/socket.c:2680 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 45: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 kasansavefreeinfo+0x40/0x50 mm/kasan/generic.c:579 poisonslabobject+0xe0/0x150 mm/kasan/common.c:240 _kasanslabfree+0x37/0x60 mm/kasan/common.c:256 kasanslabfree include/linux/kasan.h:184 [inline] slabfreehook mm/slub.c:2252 [inline] slabfree mm/slub.c:4473 [inline] kmemcachefree+0x145/0x350 mm/slub.c:4548 dstdestroy+0x2ac/0x460 net/core/dst.c:124 rcudobatch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree. ---truncated---(CVE-2024-44987)

In the Linux kernel, the following vulnerability has been resolved:

xhci: Fix Panther point NULL pointer deref at full-speed re-enumeration

re-enumerating full-speed devices after a failed address device command can trigger a NULL pointer dereference.

Full-speed devices may need to reconfigure the endpoint 0 Max Packet Size value during enumeration. Usb core calls usbep0reinit() in this case, which ends up calling xhciconfigureendpoint().

On Panther point xHC the xhciconfigureendpoint() function will additionally check and reserve bandwidth in software. Other hosts do this in hardware

If xHC address device command fails then a new xhcivirtdevice structure is allocated as part of re-enabling the slot, but the bandwidth table pointers are not set up properly here. This triggers the NULL pointer dereference the next time usbep0reinit() is called and xhciconfigureendpoint() tries to check and reserve bandwidth

[46710.713538] usb 3-1: new full-speed USB device number 5 using xhcihcd [46710.713699] usb 3-1: Device not responding to setup address. [46710.917684] usb 3-1: Device not responding to setup address. [46711.125536] usb 3-1: device not accepting address 5, error -71 [46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008 [46711.125600] #PF: supervisor read access in kernel mode [46711.125603] #PF: errorcode(0x0000) - not-present page [46711.125606] PGD 0 P4D 0 [46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI [46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.32 #1 [46711.125620] Hardware name: Gigabyte Technology Co., Ltd. [46711.125623] Workqueue: usbhubwq hubevent [usbcore] [46711.125668] RIP: 0010:xhcireservebandwidth (drivers/usb/host/xhci.c

Fix this by making sure bandwidth table pointers are set up correctly after a failed address device command, and additionally by avoiding checking for bandwidth in cases like this where no actual endpoints are added or removed, i.e. only context for default control endpoint 0 is evaluated.(CVE-2024-45006)

Database specific
{
    "severity": "High"
}
References

Affected packages

openEuler:20.03-LTS-SP4 / kernel

Package

Name
kernel
Purl
pkg:rpm/openEuler/kernel&distro=openEuler-20.03-LTS-SP4

Affected ranges

Type
ECOSYSTEM
Events
Introduced
0Unknown introduced version / All previous versions are affected
Fixed
4.19.90-2409.4.0.0295.oe2003sp4

Ecosystem specific

{
    "src": [
        "kernel-4.19.90-2409.4.0.0295.oe2003sp4.src.rpm"
    ],
    "x86_64": [
        "bpftool-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "bpftool-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-debugsource-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-devel-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-source-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-tools-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-tools-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "kernel-tools-devel-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "perf-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "perf-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "python2-perf-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "python2-perf-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "python3-perf-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm",
        "python3-perf-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.x86_64.rpm"
    ],
    "aarch64": [
        "bpftool-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "bpftool-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-debugsource-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-devel-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-source-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-tools-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-tools-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "kernel-tools-devel-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "perf-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "perf-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "python2-perf-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "python2-perf-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "python3-perf-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm",
        "python3-perf-debuginfo-4.19.90-2409.4.0.0295.oe2003sp4.aarch64.rpm"
    ]
}