Hi! This one is actually quite interesting. Untrusted users should not normally have shell access on embedded systems, but it highlights topic of coredumps. Default config of coredumping is unsuitable

Hi! I have reviewed patches and they look okay to me. I'll proceed with testing. Do we have suitable board in the test lab / is there plan to add one? Best regards, Pavel

Hi! I don't see anything obviously wrong. Thanks and best regards, Pavel

Hi! Hmm. Fun. 1e98ffea5a8935ec040ab72299e349cb44b8defd may have a clue: This leads to kernel pointer leaks if a match/target is set and then read back to userspace. So that sounds like KASLR workaroun

Hi! There is first release of 5.10-cip-rt kernel available at kernel.org. Trees are available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-5.10.y-cip-rt https://gi

Hi! -cip-rt branch is available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-5.10.y-cip-rt and it passes basic testing we do on gitlab. More testing would be welco

Hi! New realtime trees should be available at kernel.org. Trees are available at https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/log/?h=linux-4.19.y-cip-rt https://git.kernel.org/pub

Hi! Thank you, but it looks like they are rejecting the email :-(. <kernelci@groups.io>: host lb01.groups.io[45.79.81.153] said: 500 This message has been flagged as spam. (in reply to end of DATA com

#kernelci

Hi! I did not find the "New regression, last pass" summary, but clicking on testcase path indeed gave me failing and passing dmesg. Working test says: 07:05:59.319716 <4>[ 16.957513] cdn-dp fec00000.d

#kernelci

Hi! So this has enough information to tell me that we have a kernel problem there, good: 02:08:17.792502 <6>[ 18.847320] omap-mailbox 4a0f4000.mailbox: omap mailbox rev 0x400 02:08:17.800596 <0>[ 18.8

#kernelci

Hi! So... I tried to understand this report, and still could not. First problem is actually in the From: line. By placing bot there, it is not clear who is responsible for this, and if someone reads r

#kernelci

Hi! As far as I can tell, logic is quite simple there and the patch would look like this. Whether the final result works and closes the security hole is different question. Best regards, Pavel commit

Hi! > > CVE-2021-3640: UAF in sco_send_frame function > > > > 5.10 and 5.15 are fixed this week. > > > > Fixed status > > > > mainline: [99c23da0eed4fd20cae8243f2b51e10e66aa0951] > > stable/5.10: [4df

Hi! Interesting. commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 Author: Takashi Iwai <tiwai@...> Says: This should be the last piece for fixing CVE-2021-3640 after a few already queued fixes. Whi

Hi! Thank you. Looks good to me, Reviewed-by: Pavel Machek <pavel@...> Best regards, Pavel

Hi! This looks good. I believe this is too simple. We should include patch titles, so that it is easier to review whole series. I also believe we should include related patches from 4.19/4.4, so that

Hi! Furthermore, CIP members should really not be using code from staging. This one looks rather easy to backport. It failed only because reformatting of the printk. Would it make sense to ask why it

Hi! I'm sorry. Warning was clear, but I did not open the email... I was reviewing patches for 5.10.77. Best regards, Pavel

Hi! This seems to be fixed in stable/4.4, too, as 61a811e8f5229264b822361f8b23d7638fd8c914. And cip-kernel-sec says so, good. AFAICT the vulnerability was introduced by 1ef6f7c9390f in 5.9-rc3. But th

Hi! Sorry, I missed the meeting. There are public holidays today, and I'm quite busy this week. From last irc meeting, I was reviewing 5.10.76. Best regards, Pavel