The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net/sched: act_ct: fix wild memory access when clearing fragments

while testing re-assembly/re-fragmentation using act_ct, it's possible to observe a crash like the following one:

KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:inetfragrbtreepurge+0x50/0xc0 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160 FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> inetfragdestroy+0xa9/0x150 calltimerfn+0x2d/0x180 runtimersoftirq+0x4fe/0xe70 _dosoftirq+0x197/0x5a0 irqexitrcu+0x1de/0x200 sysvecapictimerinterrupt+0x6b/0x80 </IRQ>

when actct temporarily stores an IP fragment, restoring the skb qdisc cb results in putting random data in FRAGCB(), and this causes those "wild" memory accesses later, when the rbtree is purged. Never overwrite the skb cb in case tcfcthandle_fragments() returns -EINPROGRESS.(CVE-2021-47014)

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

udp: skip L4 aggregation for UDP tunnel packets

If NETIFFGROFRAGLIST or NETIFFGROUDPFWD are enabled, and there are UDP tunnels available in the system, udpgroreceive() could end-up doing L4 aggregation (either SKBGSOUDPL4 or SKBGSOFRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header.

That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc.

Just skip the SKBGSOUDPL4 and SKBGSOFRAGLIST code path if the current packet could land in a UDP tunnel, and let udpgroreceive() do GRO via udpsk(sk)->gro_receive.

The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets.

Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity.

v1 -> v2: - hopefully clarify the commit message(CVE-2021-47036)

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

media: pvrusb2: fix use after free on context disconnection

Upon module load, a kthread is created targeting the pvr2contextthreadfunc function, which may call pvr2contextdestroy and thus call kfree() on the context object. However, that might happen before the usb hubevent handler is able to notify the driver. This patch adds a sanity check before the invalid read reported by syzbot, within the context disconnection call stack.(CVE-2023-52445)

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

block: add check that partition length needs to be aligned with block size

Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, biotruncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling biointegrity_free.(CVE-2023-52458)

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

net: usb: smsc75xx: Fix uninit-value access in _smsc75xxread_reg

syzbot reported the following uninit-value access issue:

===================================================== BUG: KMSAN: uninit-value in smsc75xxwaitready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xxbind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usbhubwq hubevent Call Trace: _dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x21c/0x280 lib/dumpstack.c:118 kmsanreport+0xf7/0x1e0 mm/kmsan/kmsanreport.c:121 _msanwarning+0x58/0xa0 mm/kmsan/kmsaninstr.c:215 smsc75xxwaitready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xxbind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnetprobe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usbprobeinterface+0xece/0x1550 drivers/usb/core/driver.c:374 reallyprobe+0xf20/0x20b0 drivers/base/dd.c:529 driverprobedevice+0x293/0x390 drivers/base/dd.c:701 _deviceattachdriver+0x63f/0x830 drivers/base/dd.c:807 busforeachdrv+0x2ca/0x3f0 drivers/base/bus.c:431 _deviceattach+0x4e2/0x7f0 drivers/base/dd.c:873 deviceinitialprobe+0x4a/0x60 drivers/base/dd.c:920 busprobedevice+0x177/0x3d0 drivers/base/bus.c:491 deviceadd+0x3b0e/0x40d0 drivers/base/core.c:2680 usbsetconfiguration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usbgenericdriverprobe+0x138/0x300 drivers/usb/core/generic.c:241 usbprobedevice+0x311/0x490 drivers/usb/core/driver.c:272 reallyprobe+0xf20/0x20b0 drivers/base/dd.c:529 driverprobedevice+0x293/0x390 drivers/base/dd.c:701 _deviceattachdriver+0x63f/0x830 drivers/base/dd.c:807 busforeachdrv+0x2ca/0x3f0 drivers/base/bus.c:431 _deviceattach+0x4e2/0x7f0 drivers/base/dd.c:873 deviceinitialprobe+0x4a/0x60 drivers/base/dd.c:920 busprobedevice+0x177/0x3d0 drivers/base/bus.c:491 deviceadd+0x3b0e/0x40d0 drivers/base/core.c:2680 usbnewdevice+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hubportconnect drivers/usb/core/hub.c:5208 [inline] hubportconnectchange drivers/usb/core/hub.c:5348 [inline] portevent drivers/usb/core/hub.c:5494 [inline] hubevent+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 processonework+0x1688/0x2140 kernel/workqueue.c:2269 workerthread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:293

Local variable ----buf.i87@smsc75xxbind created at: _smsc75xxreadreg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xxwaitready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xxbind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 _smsc75xxreadreg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xxwaitready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482

This issue is caused because usbnetreadcmd() reads less bytes than requested (zero byte in the reproducer). In this case, 'buf' is not properly filled.

This patch fixes the issue by returning -ENODATA if usbnetreadcmd() reads less bytes than requested.(CVE-2023-52528)

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

wifi: wfx: fix possible NULL pointer dereference in wfxsetmfp_ap()

Since 'ieee80211beaconget()' can return NULL, 'wfxsetmfpap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfxstart_ap()' as well. Compile tested only.(CVE-2023-52593)

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

jfs: fix slab-out-of-bounds Read in dtSearch

Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error.

Dave: Set return code to -EIO(CVE-2023-52602)

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

UBSAN: array-index-out-of-bounds in dtSplitRoot

Syzkaller reported the following issue:

oop0: detected capacity change from 0 to 32768

UBSAN: array-index-out-of-bounds in fs/jfs/jfsdtree.c:1971:9 index -2 is out of range for type 'struct dtslot [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1b1/0x28e lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:151 [inline] _ubsanhandleoutofbounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfsdtree.c:1971 dtSplitUp fs/jfs/jfsdtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfsdtree.c:863 jfsmkdir+0x757/0xb00 fs/jfs/namei.c:270 vfsmkdir+0x3b3/0x590 fs/namei.c:4013 domkdirat+0x279/0x550 fs/namei.c:4038 _dosysmkdirat fs/namei.c:4053 [inline] _sesysmkdirat fs/namei.c:4051 [inline] _x64sysmkdirat+0x85/0x90 fs/namei.c:4051 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 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 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 </TASK>

The issue is caused when the value of fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was able to produce value less than -1 which cause the error. This patch simply add the change for the values less than 0.

The patch is tested via syzbot.(CVE-2023-52603)

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

FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree

Syzkaller reported the following issue:

UBSAN: array-index-out-of-bounds in fs/jfs/jfsdmap.c:2867:6 index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]') CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2d0 lib/dumpstack.c:106 ubsanepilogue lib/ubsan.c:217 [inline] _ubsanhandleoutofbounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfsdmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfsdmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfsdmap.c:2331 dbFreeDmap fs/jfs/jfsdmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfsdmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfstxnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfstxnmgr.c:2664 [inline] jfslazycommit+0x47a/0xb70 fs/jfs/jfstxnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 retfromfork+0x48/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:304

</TASK>

Kernel panic - not syncing: UBSAN: paniconwarn set ... CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x1e7/0x2d0 lib/dumpstack.c:106 panic+0x30f/0x770 kernel/panic.c:340 checkpaniconwarn+0x82/0xa0 kernel/panic.c:236 ubsanepilogue lib/ubsan.c:223 [inline] _ubsanhandleoutofbounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfsdmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfsdmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfsdmap.c:2331 dbFreeDmap fs/jfs/jfsdmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfsdmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfstxnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfstxnmgr.c:2664 [inline] jfslazycommit+0x47a/0xb70 fs/jfs/jfstxnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 retfromfork+0x48/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:304 </TASK> Kernel Offset: disabled Rebooting in 86400 seconds..

The issue is caused when the value of lp becomes greater than CTLTREESIZE which is the max size of stree. Adding a simple check solves this issue.

Dave: As the function returns a void, good error handling would require a more intrusive code reorganization, so I modified Osama's patch at use WARNONONCE for lack of a cleaner option.

The patch is tested via syzbot.(CVE-2023-52604)