The Linux Kernel, the operating system core itself.

Security Fix(es):

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

i2c: xiic: fix reference leak when pmruntimeget_sync fails

The PM reference count is not expected to be incremented on return in xiicxfer and xiici2c_remove.

However, pmruntimeget_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.

Replace it with pmruntimeresumeandget to keep usage counter balanced.(CVE-2020-36778)

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

i2c: imx-lpi2c: fix reference leak when pmruntimeget_sync fails

The PM reference count is not expected to be incremented on return in lpi2cimxmaster_enable.

However, pmruntimeget_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here.

Replace it with pmruntimeresumeandget to keep usage counter balanced.(CVE-2020-36782)

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

HID: usbhid: fix info leak in hidsubmitctrl

In hidsubmitctrl(), the way of calculating the report length doesn't take into account that report->size can be zero. When running the syzkaller reproducer, a report of size 0 causes hidsubmitctrl) to calculate transferbufferlength as 16384. When this urb is passed to the usb core layer, KMSAN reports an info leak of 16384 bytes.

To fix this, first modify hidreportlen() to account for the zero report size case by using DIVROUNDUP for the division. Then, call it from hidsubmitctrl().(CVE-2021-46906)

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

ARM: footbridge: fix PCI interrupt mapping

Since commit 30fdfb929e82 ("PCI: Add a call to pciassignirq() in pcideviceprobe()"), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised.(CVE-2021-46909)

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

usb: dwc3: core: Do core softreset when switch mode

According to the programming guide, to switch mode for DRD controller, the driver needs to do the following.

To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence

To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence

Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry's testing platform[2].

So, apply the required steps along with some fixes to Yu Chen's and John Stultz's version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device.

[1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/(CVE-2021-46941)

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

openvswitch: fix stack OOB read while fragmenting IPv4 packets

running openvswitch on kernels built with KASAN, it's possible to see the following splat while testing fragmentation of IPv4 packets:

BUG: KASAN: stack-out-of-bounds in ipdofragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367

CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dumpstack+0x92/0xc1 printaddressdescription.constprop.7+0x1a/0x150 kasanreport.cold.13+0x7f/0x111 ipdofragment+0x1b03/0x1f60 ovsfragment+0x5bf/0x840 [openvswitch] doexecuteactions+0x1bd5/0x2400 [openvswitch] ovsexecuteactions+0xc8/0x3d0 [openvswitch] ovspacketcmdexecute+0xa39/0x1150 [openvswitch] genlfamilyrcvmsgdoit.isra.15+0x227/0x2d0 genlrcvmsg+0x287/0x490 netlinkrcvskb+0x120/0x380 genlrcv+0x24/0x40 netlinkunicast+0x439/0x630 netlinksendmsg+0x719/0xbf0 socksendmsg+0xe2/0x110 _syssendmsg+0x5ba/0x890 syssendmsg+0xe9/0x160 _syssendmsg+0xd3/0x170 dosyscall64+0x33/0x40 entrySYSCALL64afterhwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0

The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch]

this frame has 2 objects: [32, 144) 'ovsdst' [192, 424) 'ovsrt'

Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00

for IPv4 packets, ovsfragment() uses a temporary struct dstentry. Then, in the following call graph:

ipdofragment() ipskbdstmtu() ipdstmtumaybeforward() ipmtu_locked()

the pointer to struct dstentry is used as pointer to struct rtable: this turns the access to struct members like rtmtulocked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovsfragment(), similarly to what is done for IPv6 few lines below.(CVE-2021-46955)

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

ethernet:enic: Fix a use after free bug in enichardstart_xmit

In enichardstartxmit, it calls enicqueuewqskb(). Inside enicqueuewqskb, if some error happens, the skb will be freed by devkfreeskb(skb). But the freed skb is still used in skbtx_timestamp(skb).

My patch makes enicqueuewqskb() return error and goto spinunlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961.(CVE-2021-46998)

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

ARM: 9064/1: hwbreakpoint: Do not directly check the event's overflowhandler hook

The commit 1879445dfa7b ("perf/core: Set event's default ::overflowhandler()") set a default event->overflowhandler in perfeventalloc(), and replace the check event->overflowhandler with isdefaultoverflowhandler(), but one is missing.

Currently, the bp->overflowhandler can not be NULL. As a result, enablesingle_step() is always not invoked.

Comments from Zhen Lei:

https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/(CVE-2021-47006)

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

net:emac/emac-mac: Fix a use after free in emacmactxbufsend

In emacmactxbufsend, it calls emactxfilltpd(..,skb,..). If some error happens in emactxfilltpd(), the skb will be freed via devkfreeskb(skb) in error branch of emactxfilltpd(). But the freed skb is still used via skb->len by netdevsent_queue(,skb->len).

As i observed that emactxfill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later.(CVE-2021-47013)

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

bnxt_en: Fix RX consumer index logic in the error path.

In bnxtrxpkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxtdiscardrx() is not correct. We should be passing the current index (tmprawcons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this:

#0 [ffff9bbcdf5c39a8] machinekexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] _crashkexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oopsend at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] nocontext at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] _badareanosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] badareanosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] _dopagefault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] dopagefault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] pagefault at ffffffff9bc015c5 [exception RIP: bnxtrxpkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018(CVE-2021-47015)

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

vsock/virtio: free queued packets when closing socket

As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work.

To avoid future issues, let's use the new virtiotransportremovesock() to drain the RX queue before removing the socket from the afvsock lists calling vsockremovesock().

[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9(CVE-2021-47024)

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

io_uring: fix overflows checks in provide buffers

Colin reported before possible overflow and sign extension problems in ioprovidebuffersprep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce ("iouring: fix provide_buffers sign extension").

Do that with help of check<op>overflow helpers. And fix struct ioprovidebuf::len type, as it doesn't make much sense to keep it signed.(CVE-2021-47040)

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

Drivers: hv: vmbus: Use after free in _vmbusopen()

The "openinfo" variable is added to the &vmbusconnection.chnmsglist, but the error handling frees "open_info" without removing it from the list. This will result in a use after free. First remove it from the list, and then free it.(CVE-2021-47049)

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

phonet/pep: refuse to enable an unbound pipe

This ioctl() implicitly assumed that the socket was already bound to a valid local socket name, i.e. Phonet object. If the socket was not bound, two separate problems would occur:

1) We'd send an pipe enablement request with an invalid source object. 2) Later socket calls could BUG on the socket unexpectedly being connected yet not bound to a valid object.(CVE-2021-47086)

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:

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)

A race condition was found in the Linux kernel's scsi device driver in lpfcunregisterfcf_rescan() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

(CVE-2024-24855)